[
https://issues.apache.org/jira/browse/QPID-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522254#comment-14522254
]
Rob Godfrey commented on QPID-6518:
-----------------------------------
The problem with the approach you've taken is that for other use cases (dare I
say the common one), where no-one else is calling interrupt on the thread, the
act of closing the connection from another thread will now cause them to get
InterruptedExceptions the next time they call an interruptible method since the
interrupted flag caused by the act of closing will now not be cleared.
If you are relying on the interrupted state being set, can you not set it
yourself in the case where receive() returns null (i.e. do
Thread.currentThread().interrupt() there)?
> Cyclic errors on thread interruption thru resetting interrupted flag
> --------------------------------------------------------------------
>
> Key: QPID-6518
> URL: https://issues.apache.org/jira/browse/QPID-6518
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.32
> Environment: WildFly 8.2.0.Final, RabbitMQ 3.5.1
> Reporter: Nikita Konev
> Assignee: Rob Godfrey
> Attachments: BasicMessageConsumer.java, OurBean.java, wildfly-log.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> When i attempt undeploy application caused backgroundProcess.interrupt() in
> OurBean.java:72, sometimes may occur InterruptedException in
> BasicMessageConsumer.receive(). It resets interrupted flag of thread that
> resulting cyclic errors because thread is not interrupted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
