Thanks again. This was an issue.
However, I've gone with an alternate implementation of suspend that
I hope makes the method clearer and me less likely to make similar
public boolean suspend(long timeout)
_new = false;
if (!_pending && !resumed && timeout > 0)
_timeout = timeout;
throw new RetryRequest();
this is in SVN and works for the chat demo.... but obviously I need
to get a few more rigorous test harnesses.
Guillaume Nodet wrote:
> Hi !
> I 'm stress testing a bit my jbi component, using the
> SelectChannelConnector and continuation, and there are some cases
> I have some the continuation timeout, even if the continuation has been
> Looking at the code, it seems that this problem can happen when the
> continuation.resume is called before the
> continuation.suspend (and this may happen in my code).
> I guess the suspend method should handle this case, by checking if the
> _resumed flag has been set to true
> by a call to resume.
> Another problem is that the continuation can be recycled for use in
> another request.
> When modifying the test as stated above, the _resumed flag is set to
> true and no one will
> set it to false. I have also added the code so that the continuation can
> be safely reused.
> Changing the code of the resume method by the following one seems to
> work fine for me.
> public boolean suspend(long timeout)
> synchronized (this)
> _new = false;
> if (_pending || _resumed)
> boolean resumed = _resumed;
> _resumed = false;
> return resumed;
> if (timeout > 0)
> _timeout = timeout;
> throw new RetryRequest();
> return _resumed;
> Guillaume Nodet
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!