bloglistLength = 10
[markup]
+[markup.goldmark]
+[markup.goldmark.renderer]
+unsafe = true
+
[markup.highlight]
lineNos = true
lineNumbersInTable = true
--- /dev/null
+---
+title: Outliner [Garden]
+tags: ["project", "outliner", "garden"]
+summary: A Garden (Continually updating) post about the current Outliner Status.
+date: 2023-11-22T01:03:25.836-05:00
+---
+
+
+This page will serve as the current state of my Outliner project.
+
+Github - https://github.com/angelor/outliner
+
+## Current Version: 0.0.1-alpha-4
+
+### Known Bugs
+
+- None
+
+### Planned Features
+
+There's no timeline on any of these features, but their current order is rougly the order that I'll be working on them on.
+
+#### Mouse Support
+
+I've been holding off on this a bit, mostly because I don't want to deal with the node-reordering during dragging/dropping. However, I think it'll be one of those things that are really helpful even if you're a keyboard only user.
+
+#### Copy Nodes
+
+Hitting `ctrl`+`c` on a hilighted node should all you to copy the content of that particular node. Pasting the node should happen in one of two ways: If you are in edit mode, it should paste just the content of the node in your current editor. If you are in navigation mode, it should paste a new copy of the node at your cursor, pushing the existing content down.
+
+This lends itself really well to "referential nodes" as well
+
+#### General Publishing
+
+General publish is working in alpha-4. I'm actually quite pleased with it so far. The configuration is abstracted away, but does expect that you're going to be operating out of the `/home` directory specifically. But, apart from that, the actual work to generate posts, inculding drag+drop support for images, and also code is allowing this to become a really all-rounded tool for me.
+
+#### Referential Node Links
+
+Each node in the outliner is saved as its own JSON file. The reason for this was to eventually implement the idea of "Referential Node Links". A single node, that can be referenced in multiple outliners. Updating the node from any of the outlines will update the node in every outline. The idea is to give you the ability to re-use certain templates/bits of code. If you hit `ctrl+shift+c` it should copy the node reference and allow you to paste that in
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
--- /dev/null
+---
+title: Rising Legends [Garden]
+tags: ["project", "rising-legends", "garden"]
+summary: A Garden (Continually updating) post about the current status of a PBBG Game I'm working on.
+date: 2023-09-01T13:52:42.461-04:00
+---
+
+
+This page will serve as the current state of [Rising Legends](https://www.risinglegends.net), a Persistent Browser-Based Game.
+
+## Known Bugs With Current Release
+
+- When you swap apps on mobile the websocket disconnects... then it reconnects it always throws you back to the Explore screen.
+
+- With the introduction of the Vigor System, the balancing of everything is completely out of whack...
+
+---
+
+{{% include "./static/CHANGELOG.md" %}}
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
--- /dev/null
+---
+title: Links
+date: 2024-02-05T09:41:19.161-05:00
+---
+
+
+Here's a collection of blogs that I enjoy and try and keep up with. They aren't listed in any particular order. I'm really looking to re-live the nostalgia of early webrings in the pre web2.0 era. Infact, at some point I'm going to have to move this blog off GitHub pages so that I can start experimenting with some of the IndieWeb functionality...
+
+---
+
+### Drew Devaults Blog - https://drewdevault.com
+
+Drew’s blog has been something I’ve long followed. He’s the guy behind [SourceHut](https://sourcehut.org) which has quickly become my favourite spot to host projects. He has a long list of projects that he works on outside of that, but almost everything he does is open source in some way. His blog contains a bit of everything from software to politics.
+
+### Rosano - https://utopia.rosano.ca
+
+Rosano is someone I had known a long time ago. We drifted apart for some time.. and then randomly discovered that we had both ended up working in software somehow. Rosano has had the courage to do something I have never been able to - dedicate himself to making things better. We all like to make things better for people as things cross our path - but Rosano seems to made it a lifestyle choice for him. Part digital nomad part philosophy, his blog is something I subscribe to via email because I don’t like to miss a post. He also has a wonderful podcast where he talks to non-celebrities wherever he finds himself.
+
+### Dave Winer - https://scripting.com
+
+Dave has been involved in the creaction of RSS, almost all of the surrounding tooling, and a bunch of uses (OPML, Podcasts, Blogging?). He was also my first introduction to the world of outliners and rivers of news. He’s also really easy to get in touch with if you’re interested in any of those things. I definitely recommend checking out his blog, if only to keep up with the tools and projects that he works on.
+
+### Caleb (Zalaah) - https://cardboardmachete.com/blog
+
+Zalaah is a pretty well known member of the Persistent Browser-based Gaming community. He’s got a bunch of different games out and still manages to find time to be very involved in the community. He has some really interesting posts on his blog about the approach he takes with various components of his PBBGs and the technical minutae around it.
+
+### Gaffer on Games - https://www.gafferongames.com
+
+Glenn’s website is the primer on working on multiplayer networking for gaming. In addition to incredibly detailed posts about things like “Building reliability over UDP” or LERP/SLERPing. When I was first starting out building multiplayer systems in gaming his blog (andeventually the video posts) were absolutely vital to geting going. If you’re ever curious about that stuff I definetely recommend you take a peek at their site and take plenty of notes.
+
+
+
+
+
\ No newline at end of file
--- /dev/null
+---
+title: Amplify docker limitations
+summary: Amplify has some odd docker limitations it doesn't want to fix
+tags: ["aws", "docker", "amplify"]
+date: 2023-12-05T05:16:29.288-05:00
+---
+
+
+I've recently had the chance to do some work wtih Amplify in AWS and I'm surprised how simultaneously feature rich and half baked it is. It seems if you're in to click-ops you'll be fine in Amplify until you hit a problem.
+
+If you're deploying through amplify you'll eventually hit this problem:
+
+```[BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE: Unable to pull customer's container image. CannotPullContainerError: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit]```
+
+Which seems perfectly reasonable at first glance. Nowhere in your project setup did you really define credentials for your docker account.
+
+But if you dig a bit it gets weird: You actually can't define credentials for a docker account.. and the limits for the free tier are high enough that you probably wouldn't hit them with a small team - 100 pulls every 6 hours per IP.
+
+Turns out you actually share a build pool with other users in amplify - which makes sense. But that in turn means that every so often your build pool will hit the limits for pulling containers from docker hub. And since there's no way to set credentials for your pull.. you're just kinda left hoping that if you retry things will work. There's probably a large enough build pool that it works sometimes, but there are reports of it taking up to an hour or so.
+
+So you think: Oh yeah, no worries -> I'll just set up ECR, and configure Amplify to grab my image from that repo instead. But ECR is a non-starter. It turns out that you can't assign any kind of roles to amplify to allow authentication against an ECR.. so if you're hosting your image in ECR, you have to make the entire repo publicly accessible.
+
+If you're using customized images unfortunately this is really the only way to go. You have to build and deploy to ECR and make the repo publicly available.
+
+If you're using pre-built images, amazon actually has their own public replica of popular docker images [https://gallery.ecr.aws/](https://gallery.ecr.aws/). If you can find your image on there then you can reference it in the build params for your Amplify project.
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
---
title: Chrome HTTP Request stuck in "Stalled" State
summary: Chrome reports that a request is stuck in a "stalled" state and I try and figure out why
-tags: ["chrome" ,"iis", "investigation", "explanation"]
-draft: true
-date: 2023-05-30T11:24:48.041-04:00
+tags: ["chrome", "investigation", "explanation"]
+draft: false
+date: 2023-06-20T12:30:56.105-04:00
---
The first thing I did was attempt to replicate it and capture a `.har` file that I could share with anyone else that was interested. This part was easy - just popping open the network tab, navigating to the app on a test env, and then clicking every link that would trigger a network request. After about 30-40 seconds I had replicated the event
-LINK TO TIMING WHERE IT SHOES THE QUEUE
+
So we can clearly see here that the request took 2 minutes and the entirety of that time the connection was stuck in the `stalled` state. That indicates one of two things:
One tool that chrome has to diagnose networking issues is hidden away at `chrome://net-export`. It generates a very VERY detailed log of everything network related that chrome is aware of.
-IMAGE OF CHROME CAPTURE NETWORK LOG
+
-I unchecked the `strip private information` option and told it to include cookies + credentials and started logging it to disk. Then I swapped back to my tab and replicated the issue. Waited a few seconds, and then went back and ended the captuer session.
+I unchecked the `strip private information` option and told it to include cookies + credentials and started logging it to disk. Then I swapped back to my tab and replicated the issue. Waited a few seconds, and then went back and ended the capture session.
Once you get that capture file, you have to head over to https://netlog-viewer.appspot.com and import it. There's a TON of information here, and honestly I didn't even look at half of it. The only two things I cared about were the "Events" and "Timeline" sections. The Timeline really makes no sense until you have a idea of when your actual network event happened, so we can skip that and jump right over to Events
There will likely be a lot of events. The "filter" at the top never worked for me given the sheer size of the events.. but scrolling through them all was just fine and eventually I found the URL request that caused the issue. If you click on the event it will display a bunch of debug information about the request.
-IMAGE OF EVENT 169281
+
As you can see.. suddenly there's a HUGE jump in time from `66807` to `187631`. We've confirmed now that this is a problem that's occurring within the CORS preflight request specifically, and it's just getting rolled into the `stalled` state. The log viewer makes it trivial to dig down into the events and if you click on the details of the `HTTP_STREAM_JOB_CONTROLLER` event you can see some more details.
-IMAGE OF EVENT 169283
+
Here again, we see that there is a definitely delay when it attempts to call `HTTP_STREAM_REQUEST_STARTED_JOB`
-IMAGE OF EVENT 169284
+
And now we can easily see the problem: `SOCKET_POOL_STALLED_MAX_SOCKETS_PER_GROUP`
-For some reason, the socket pool dedicated to this particular group (in this case grouped by FQDN) is filled up and so it can't actually make the next request. So it just sits there.. until suddenly a socket is available (2 minutes later) and it is able to complete the rest of the request as expected.
+In HTTP1.1 each tab in your browser is configured to only make a certain number of requests per FQDN at the same time.This is one of the reasons why we load "static assets" on a different subdomain. By loading static assets on a separate FQDN we can increase the objects that are simultaneously loaded in our tab providing a better experience (for some definition of experience) to our user. In HTTP2, this restriction is across every single tab in your browser. For chrome, it can only instantiate 6 concurrent connections to an FQDN. This is because your connections are persistent in http2 and you don't need to deal with the initialization handshakes on every request. The connection, once opened, is continually reused.
+
+<span style="font-family: sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal;">For some reason, the socket pool dedicated to this particular FQDN gets filled up and so it can't actually make the next request. So it just sits there.. until suddenly a socket is available (2 minutes later) and it is able to complete the rest of the request as expected. The "suddenly" is likely due to the default socket timeout. Once that timeout is hit, Chrome kills the connection and opens a new one and suddenly our request works again.</span><br>
We can dig even further! Since we know that this is happening on an HTTP2 call, we can filter our events to only show us the http2 connections and that paints a more serious picture!
-Every since one of our http2 sockets is getting set a `GOAWAY` frame by the server.. but notice that it says `NO_ERROR`. Some quick research shows us that this is actually part of the "graceful shutdown" strategy. The server tells the client to `GOAWAY` but there's `NO_ERROR`. This is the clients indication to wrap up its work because the server is going to officially disconnect soon. Except that final disconnect frame is never sent. So as far as chrome is concerned, we're still happily connected so it returns the connection to the pool. But the server has disconnected.
+
+
+Every one of our http2 sockets is getting sent a `GOAWAY` frame by the server.. but notice that it says `NO_ERROR`. This generally indicates that the server is telling the client that it will be shutting down this socket and. The `GOAWAY` frame also tells the client what the last stream that it processed was. This is so that the client can resend any data that it needs to on a new connection. What should happen is that after this frame, the connection is ended by both parties and we move on to a new one. In practice, it happens after a following `GOAWAY` frame that indicates the connection is now dead. Except that final disconnect frame is never sent. So as far as chrome is concerned, we're still happily connected so it returns the connection to the pool. But the server has disconnected.
+
+So it just sits there trying to use the connection again, times out, and then closes and opens a new connection! And so we tracked down the mysterious slow-down and also used some cool tools in the process!
+
+---
+
+One thing I do want to note: This seems like a really straight forward problem - but that's just in hindsight. In the moment there's lots of googling and staring off into space trying to remember obscure keywords. I have a really bad memory, and so one of the things I do is memorize keywords/ideas rather than content because there's just too much to remember. In this way I can ensure that I can find the pieces of information I need when I need to. In this case the keys things were:
+
+- chrome has some kind of detailed network log
+
+- browsers like to fold CORS requests into the main request for reporting
+
+- http2 has a max connection limit across your browser
+
+The rest of the information used is all derivable from those keys and a search engine.
Home / xangelo.ca.git / commitdiff