On Nov 21, 2018, at 10:17 AM, Nikola Mitev <n...@mitev.eu> wrote: > > It happens about once a month on a site > with 10-20 logins daily. Once it happens to a user, it keeps happening > for that user only.
You haven’t said which engines you’re using. It might be simplest to just post the config.yml file and the $environment.yml file it loads, if any. It might also help to know the HTTP server configuration. Apache vs Starman, FastCGI vs HTTP proxying, etc. I suspect you’ve got a parallel access locking problem that only shows up when two users happen to hit the app at the same time, but that’s just speculation on the information you’ve given so far. > I don't have an explicit check on cookie size - not sure how to check > it doesn't exceed 4K Unless you’re using Dancer2::Session::Cookie, I don’t see how that can be the case. That’s the whole point of separating the notion of cookie and session: all of the real per-user data goes into the Session object, and the cookie is used only to look that Session object up. But you don’t need to guess: any modern browser’s developer toolset will give you the cookie value. It should be just a small-ish blob of hex noise. > I am looking for general advice on how to > troubleshoot this but any ideas at all will be very much appreciated. What happens if you switch to Dancer2::Session::YAML? It’s slower, but for volumes as low as yours, it shouldn’t matter. The benefit is that you can then inspect the session objects directly when this happens. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
