See
https://grizzly.dev.java.net/issues/show_bug.cgi?id=407
Thanks
On 01/17/2009 01:12 AM, Oleksiy Stashok wrote:
> Hi Sebastien,
>
> my thought is that is bug :)
> Can you pls. file an issue with testcase? I'll fix it on Monday.
>
> Thank you.
>
> WBR,
> Alexey.
>
> On Jan 17, 2009, at 1:09 , Sebastian Dehne wrote:
>
>> Hi guys,
>>
>> I ran into the following exception today (using 1.9.3)
>>
>> java.lang.IllegalMonitorStateException
>> at
>> java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
>>
>> at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1175)
>>
>> at
>> java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
>> at
>> com.sun.grizzly.async.AbstractAsyncQueueWriter.onWrite(AbstractAsyncQueueWriter.java:378)
>>
>> at
>> com.sun.grizzly.async.AsyncQueueWriterContextTask.doCall(AsyncQueueWriterContextTask.java:86)
>>
>> at
>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>>
>> at
>> com.colibria.execution.ThreadPoolImplCore$4.call(ThreadPoolImplCore.java:171)
>>
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
>>
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>> The problems seems to be that I'm using the same thread, which call
>> callbackHandler.onWriteCompleted(), to schedule the next msg to be
>> sent. Let me explain in more detail:
>>
>> 1. thread1 owns the lock and calls
>> queueRecord.callbackHandler.onWriteCompleted()
>> 2. the implementation behind this callbackHandler directs thread1 back
>> to this AbstractAsyncQueueWriter and calls write().
>> 3. thread1 releases the lock in the final-block in this very write()
>> method without having acquired it for a second time, leaving the lock
>> in the "unlock" state.
>> 4. while thread1 is still inside the
>> queueRecord.callbackHandler.onWriteCompleted() method and thinks it
>> still own the lock thread2 comes along and calls onWrite() and
>> acquires the lock
>> 5. thread1 returns from the
>> queueRecord.callbackHandler.onWriteCompleted() method and calls
>> unlock, which causes the exception.
>>
>> My first guess for a solution would be to ensure that a lock is always
>> acquired before given up, instead of always unlocking in the final block.
>>
>> Not allowing the same thread to call write() again is not really an
>> options, since creating a new task for each
>> queueRecord.callbackHandler.onWriteCompleted() call would impact
>> performance.
>>
>> What are your thoughts on this?
>>
>> Thanks
>> Sebastian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>