Project

General

Profile

Actions

Bug #2826

closed

The very first display of a node fails

Added by Nicolas CHARLES over 12 years ago. Updated about 12 years ago.

Status:
Released
Priority:
3
Category:
Web - Nodes & inventories
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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

Actions #1

Updated by Jonathan CLARKE over 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.

Actions #2

Updated by Nicolas CHARLES over 12 years ago

  • Status changed from 2 to Pending technical review
  • % Done changed from 0 to 100
Actions #3

Updated by François ARMAND over 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 ?

Actions #5

Updated by Nicolas CHARLES over 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)

Actions #6

Updated by Nicolas PERRON about 12 years ago

  • Target version changed from 2.4.0~rc1 to 2.4.0~beta5
Actions #7

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.

Actions #8

Updated by François ARMAND about 12 years ago

Bug for lazy is #2910

Actions #9

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

Actions

Also available in: Atom PDF