Bug #2826
closed
The very first display of a node fails
Added by Nicolas CHARLES over 11 years ago.
Updated over 11 years ago.
Category:
Web - Nodes & inventories
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
- Status changed from New to 2
- Assignee changed from François ARMAND to Nicolas CHARLES
- Priority changed from 1 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.
- Status changed from 2 to Pending technical review
- % Done changed from 0 to 100
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 ?
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)
- Target version changed from 2.4.0~rc1 to 2.4.0~beta5
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.
- Status changed from Pending technical review to Released
Ok pour the removal of the lazy ! Thank you Francois
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Nicolas PERRON