||marcus.priesch, rouilj, schlatterbeck
In message <email@example.com>,
Ralf Schlatterbeck writes:
>Ralf Schlatterbeck added the comment:
>On Thu, Apr 28, 2022 at 08:37:14AM +0000, Marcus Priesch wrote:
>> ps: do you have anything i can test against the preloading stuff?
>Hmm, not really. The original issue was issue2551172 where the rev
>multilinks were only there on the first request (with the standalone
>roundup_server) but not on subsequent requests when the connection was
>cached. The problem did *not* materialize with WSGI. And the first
>request after the cached connection timed out was OK again.
>So I really don't know how to come up with an easy test for this.
>Especially when WSGI is involved (although *this* problem didn't occur
>with WSGI another one might be specific to WSGI).
We do have a live_server test using the wsgi backend in the test
bed. Not sure if it's useful for this problem.
>But maybe your patches make the code *less* brittle in this part so that
>the tracker (as opposed to the DB) is only always initialized once on
>startup -- for WSGI or other frontends.
Roundup-server is supposed to have its own debug mode that reloads
templates if they have changed. I thought there was a debug mode that
made the same thing happen in the other front end deployment
mechanisms. I rely on this extensvely for tracker development. Not
having hot reload can mean literally hundreds of server restarts as
template changes are done.
+ rouilj, schlatterbeck, marcus.priesch|
|2022-04-28 12:48:49||rouilj||link||issue2551184 messages|