Roundup Tracker - Issues

Message7474

Author rouilj
Recipients marcus.priesch, rouilj, schlatterbeck
Date 2022-04-28.12:48:49
Message-id <20220428124843.0B3F76A028A@pe15.cs.umb.edu>
In-reply-to <20220428093811.l6y4srn5qt4bzxcw@runtux.com>
Hi all:

In message <20220428093811.l6y4srn5qt4bzxcw@runtux.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.
History
Date User Action Args
2022-04-28 12:48:49rouiljsetrecipients: + rouilj, schlatterbeck, marcus.priesch
2022-04-28 12:48:49rouiljlinkissue2551184 messages
2022-04-28 12:48:49rouiljcreate