Bugzilla – Full Text Bug Listing
| Summary: | Hostname entry is very slow in New Server Wizard | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Rajiv Senthilnathan <rajiv.senthilnathan> | ||||||||
| Component: | wst.server | Assignee: | Elson Yuen <eyuen7> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Angel Vera <arvera> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | bjustin, cbridgha, david_williams, eyuen7 | ||||||||
| Version: | unspecified | Flags: | david_williams:
pmc_approved+
arvera: pmc_approved? (raghunathan.srinivasan) arvera: pmc_approved? (naci.dai) arvera: pmc_approved? (deboer) arvera: pmc_approved? (neil.hauge) arvera: pmc_approved? (kaloyan) cbridgha: pmc_approved+ arvera: review+ |
||||||||
| Target Milestone: | 3.2.4 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| See Also: | https://git.eclipse.org/r/109045 | ||||||||||
| Whiteboard: | PMC_approved | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Rajiv Senthilnathan
The problem is caused by we are doing validation and the host name change reaction code on every character that is being typed. We can introduce a delay on the code on reacting to the host name change. We should only do the work after the user has stopped typically after a period of time, e.g. 500ms. Please assign this one to me. (In reply to comment #1) > The problem is caused by we are doing validation and the host name change > reaction code on every character that is being typed. We can introduce a delay > on the code on reacting to the host name change. We should only do the work > after the user has stopped typically after a period of time, e.g. 500ms. > > Please assign this one to me. Or even better, do the hostname validation off the UI thread. Even with a reasonable delay, if the user starts typing again while you are doing this work on the UI thread, their typing will still not update the UI until the validation work is done. The danger of doing validation off a separate thread is that we are loosing the control on the time for the delay on the validation result. The validation may not be completed and the user can click next to bypass the validation. Given that the validation is not really that long in this case and the performance delay is due to the number of calls being made, I'll suggest to stick to the original plan for delaying the validation slightly. Created attachment 177616 [details]
v1.0
Created attachment 177907 [details]
v2.0
Elson,
On your patch you used two classes from the javax.swing package. No other code in our plugins makes use of this, so I would prefer to continue not mixing the objects.
I have implemented what I think is an equivalent way of doing what you intended. But even with my changes the problem is not fully resolved :(, but it is minimized :). If the user is quick enough and he enters an invalid hostname before the validation gets kicked, a server with an invalid hostname can be created. I did a test run with the HTTP server an entering an invalid hostname for that server type and I was able (on my first try, didn't do subsequent tries) to create a server with an invalid hostname.
This by no means say that I have a better solution than what you have. But at the very minimum we should agree on:
1. there is no better solution
2. my modified version of the code is equivalent to yours (but not using any javax classes)
We ran out of time to work on the last piece of this bug, so I am moving it out to future. The problem with the newer patch is the timer does not reset itself after receiving another notification event. That means if the user type 5 characters within the wait period, the validation will be running 5 times. We are simply delaying each validation instead of reducing the number of validation. Therefore, we are not solving the original problem at all with the new proposed patch. I'll see if I can come up with a different patch to address the mentioned issue. Created attachment 194024 [details]
v3.0
Created a new patch that will fix the previous mentioned problem, i.e.:
1. The wizard next and finish buttons will be disabled during the wait period.
2. The validation will only run once after the waiting period.
Testing has been done on tomcat server creation wizard and another adopter server creation wizard and has been proven to prevent multiple validation runs when the user type the host name quickly (within 300ms).
This problem needs to be fixed since it is a fairly bad user experience. On a slower network, the user have to wait for 3 to 4 sec to type each character of the host name in the server creation wizard. On any adopter's server, it is taking 5 to 6 sec for typing each character. Within that waiting period, the GUI is not responding at all. The workaround is for the user to wait for the GUI to come back which provides a fair bad user experience. The fix on this problem is to create a timer that will wait for 300ms before trying to react to the change in host name. This change groups normal typing of the host name and do the proper validation and other work in response to the host name change on the server creation wizard. Combined with the fix on localhost check cache introduced on bugzilla 323455 earlier, this will make the GUI to response on host name that has been used before to response even more quicker. This is a performance improvement on the responsiveness of the GUI. Therefore, JUnit test does not apply. The manual GUI test has been done using the original steps on the problem description. * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such.
This problem needs to be fixed since it is a fairly bad user experience. On a slower network, the user have to wait for 3 to 4 sec to type each character of the host name in the server creation wizard.
On any adopter's server, it is taking 5 to 6 sec for typing each character. Within that waiting period, the GUI is not responding at all.
* Is there a work-around? If so, why do you believe the work-around is insufficient?
The workaround is for the user to wait for the GUI to come back which provides a fair bad user experience.
* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?
This is a performance improvement on the responsiveness of the GUI. Therefore, JUnit test does not apply. The manual GUI test has been done using the original steps on the problem description.
* Give a brief technical overview. Who has reviewed this fix?
The fix on this problem is to create a timer that will wait for 300ms before trying to react to the change in host name. This change groups normal typing of the host name and do the proper validation and other work in response to the host name change on the server creation wizard. Combined with the fix on localhost check cache introduced on bugzilla 323455 earlier, this will make the GUI to response on host name that has been used before to response even more quicker.
* What is the risk associated with this fix?
The risk on this fix is low. It is very isolated to the server creation wizard. The logic for reacting to the change after the timer has expired is unchanged. Therefore, the risk to the downstream wizard pages are fairly low.
Sounds important. Assuming Angel has reviewed, with no concerns, as indicated by the review flag. Code released to 3.2M and 3.3M on 20110427. New Gerrit change created: https://git.eclipse.org/r/109045 |