java - Working around JMS MessageConsumer.receive(long) not returning within the timeout -


messageconsumer.receive(long) allows specifying timeout on receive.

however, have found if make producer go away (e.g. killing process), receive on consumer doesn't always time out. in fact, waits forever , process never exits.

it turns out can add exceptionlistener connection, has drawbacks: (1) might errors things other operation trying perform; (2) receive() still won't complete; (3) apparently used use exceptionlistener , causing other issues don't know specifics of.

one potential hack looks viable (we're using activemq) when stall occurs, thread in wait() (this implementation-specific seems common choice.) if got exception, interrupt thread doing receive() calls.

is sane solution? there more reliable, well-known, commonly-implemented workaround issue?

instead of using receive, setup message listener. seems bug in activemq, have reported issue in jira?


Comments

Post a Comment

Popular posts from this blog

Java sticky instances of class com.mysql.jdbc.Field aggregating -

i noticed (via jmap+jhat) app leaking storing many instances com.mysql.jdbc.field  class - double checked code make sure closing preparedstatements, find few missing didn't change outcome. - preparedstatement created , closed right away - several others created @ start , reused many times - using org.apache.tomcat.jdbc.pool.datasource connection pool what can cause type of behavior? are closing of preparedstatements / result sets using: preparedstatement stmt (possible assignment here); try { // work prepared statement resultset rs; try { while (rs.next()) ... // process results } { rs.close(); } } { stmt.close(); } so guarantee result sets closed when finished (regardless of exceptions) , statements closed (regardless of exceptions)? there other ways write that, idea same. if you're doing of properly, unless have many references it's taking inordinate amount of memory, it's ok , nothing needs done it.
Read more