Bugzilla – Full Text Bug Listing
| Summary: | Suspicious timeout handling in SelectChannelEndPoint | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Przemek Bruski <sesuvqrbasuvgg> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | jetty-inbox |
| Version: | unspecified | ||
| Target Milestone: | 7.2.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
No. the intent of that method is to set the maximum time that the thread will block waiting to change from _writeBlocked to !_writeBlocked. The inner loop is because a wait can sometimes spontaneously be interrupted early, so it ticks of the time already waited an waits again. But thanks anyway for raising issues like this - it is always good to have people checking code. |
Build Identifier: Something I've found when browsing Jetty code. In org.eclipse.jetty.io.nio.SelectChannelEndPoint class: /* ------------------------------------------------------------ */ /* * Allows thread to block waiting for further events. */ @Override public boolean blockWritable(long timeoutMs) throws IOException { synchronized (this) { long start=_selectSet.getNow(); try { _writeBlocked=true; while (isOpen() && _writeBlocked) { try { updateKey(); this.wait(timeoutMs); timeoutMs -= _selectSet.getNow()-start; if (_writeBlocked && timeoutMs<=0) return false; } catch (InterruptedException e) { Log.warn(e); } } Shouldn't the "start" variable be initialised every time we start the while() loop? The same would apply to blockReadable. Reproducible: Always