Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338964 - Suspicious timeout handling in SelectChannelEndPoint
Summary: Suspicious timeout handling in SelectChannelEndPoint
Status: RESOLVED WONTFIX
Alias: None
Product: Jetty
Classification: RT
Component: server (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: 7.2.x   Edit
Assignee: Greg Wilkins CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-04 13:12 EST by Przemek Bruski CLA
Modified: 2011-03-31 18:23 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Przemek Bruski CLA 2011-03-04 13:12:09 EST
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
Comment 1 Greg Wilkins CLA 2011-03-31 18:23:54 EDT
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.