Bug #2826
closed
The very first display of a node fails
Description
I've been searching for a node in the quick search on orchestrateur-3 (searching for node debian-5-32.labo.normation.com), and I didn't have any answer (at least not in a fast enough period of time, and I got the infamous "the server cannot be contacted at this time"). It happened also during a demo with the demo on the foswiki
The logs don't show anything, and searching again shows the results
It seems to happen only the first time this event occurs (in the lifetime of the webapp ?), for any subsequent search succeeed, even with another browser or login out and in again
Interestingly, the log are empty.
This looks very much like an heisenbug, sorry about that
Updated by Jonathan CLARKE about 12 years ago
- Status changed from New to 2
- Assignee changed from François ARMAND to Nicolas CHARLES
- Priority changed from 1 (highest) to 3
- Target version changed from 2.4.0~beta4 to 2.4.0~rc1
Nicolas will try to load reports asynchronously on the node details page.
Note: the bug is not in searching for the node (contextual menu) but on displaying the node details page. Thus the workaround.
Updated by Nicolas CHARLES about 12 years ago
- Status changed from 2 to Pending technical review
- % Done changed from 0 to 100
Applied in changeset ddb9c4efefe1b7cb4d36c2d0010dde2b92ef86de.
Updated by François ARMAND about 12 years ago
Do all the "lazy" really buy us something ? I'm not at ease with them, I don't see why we should have them, and so I fear that either we will forget to add them when needed elsewhere, or that will introduce unecessary code.
Nicolas, could you please add a comment explaining why they are needed, or just remove them if the lazy loading of tabs is sufficient to workaround the bug ?
Updated by Nicolas CHARLES about 12 years ago
François ARMAND wrote:
Do all the "lazy" really buy us something ? I'm not at ease with them, I don't see why we should have them, and so I fear that either we will forget to add them when needed elsewhere, or that will introduce unecessary code.
Nicolas, could you please add a comment explaining why they are needed, or just remove them if the lazy loading of tabs is sufficient to workaround the bug ?
It feels faster with the lazy. but it's subjective. It does not seem to be the part avoiding the bug (but that's difficult to say, since my system is a bit more reactive that the test bench)
Updated by Nicolas PERRON about 12 years ago
- Target version changed from 2.4.0~rc1 to 2.4.0~beta5
Updated by François ARMAND about 12 years ago
OK, so I propose to remove them, and open a refactoring bug to mark all services as lazy and test performance improvment.
I'm making a commit for that.
Updated by Nicolas CHARLES about 12 years ago
- Status changed from Pending technical review to Released
Ok pour the removal of the lazy ! Thank you Francois