BlazeDS+ActiveMQ: non-graceful disconnection of Flex client from a durable topic does not remove it from ActiveMQ -


i'm trying make flex-based desktop application consume messages activemq topic durable subscription, using jms bridge of blazeds. basic scenario follows:

  1. messages produced other producers in topic flex client subscribed.

  2. the flex client may go offline time time, must receive messages has missed while being offline when connects blazeds again. (of course flex client connects same client id every time).

  3. it can not guaranteed flex client shut down gracefully.

everything works fine if explicitly disconnect consumer on flex side calling disconnect() - in exit handler of application. however, due #3 above, not guaranteed disconnect() called time. when flex client shuts down without calling disconnect(), seems subscription of "proxy jms client" blazeds creates , associates flex client stays active towards activemq, activemq still thinks client logged in. when flex app starts next time, unable log in blazeds because activemq refuses subscription, claiming client id taken. why , can here ensure blazeds makes "proxy jms client" offline in activemq when real flex counterpart terminates unexpectedly?

more detailed information: debugging revealed that:

  1. blazeds becomes aware of termination of flex client because prints few exceptions console when in debug mode. messages follows:

    [blazeds]23:18:13.688 [warn] endpoint id 'my-streaming-amf' closing streaming connection flexclient id '71e6466f-d91f-201c-f60a-a6cb52f95d9f' because endpoint encountered socket write error, possibly due unresponsive flexclient. clientabortexception:  java.net.socketexception: broken pipe     @ org.apache.catalina.connector.outputbuffer.doflush(outputbuffer.java:319)     @ org.apache.catalina.connector.outputbuffer.flush(outputbuffer.java:288)     @ org.apache.catalina.connector.response.flushbuffer(response.java:542)     @ org.apache.catalina.connector.responsefacade.flushbuffer(responsefacade.java:279)     @ flex.messaging.endpoints.basestreaminghttpendpoint.handleflexclientstreamingopenrequest(basestreaminghttpendpoint.java:818)     @ flex.messaging.endpoints.basestreaminghttpendpoint.servicestreamingrequest(basestreaminghttpendpoint.java:1055)     @ flex.messaging.endpoints.basestreaminghttpendpoint.service(basestreaminghttpendpoint.java:460)     @ flex.messaging.messagebrokerservlet.service(messagebrokerservlet.java:353)     @ javax.servlet.http.httpservlet.service(httpservlet.java:803)     @ org.apache.catalina.core.applicationfilterchain.internaldofilter(applicationfilterchain.java:290)     @ org.apache.catalina.core.applicationfilterchain.dofilter(applicationfilterchain.java:206)     @ org.apache.catalina.core.standardwrappervalve.invoke(standardwrappervalve.java:233)     @ org.apache.catalina.core.standardcontextvalve.invoke(standardcontextvalve.java:175)     @ org.apache.catalina.core.standardhostvalve.invoke(standardhostvalve.java:128)     @ org.apache.catalina.valves.errorreportvalve.invoke(errorreportvalve.java:102)     @ org.apache.catalina.core.standardenginevalve.invoke(standardenginevalve.java:109)     @ org.apache.catalina.connector.coyoteadapter.service(coyoteadapter.java:263)     @ org.apache.coyote.http11.http11processor.process(http11processor.java:844)     @ org.apache.coyote.http11.http11protocol$http11connectionhandler.process(http11protocol.java:584)     @ org.apache.tomcat.util.net.jioendpoint$worker.run(jioendpoint.java:447)     @ java.lang.thread.run(thread.java:680) caused by: java.net.socketexception: broken pipe     @ java.net.socketoutputstream.socketwrite0(native method)     @ java.net.socketoutputstream.socketwrite(socketoutputstream.java:92)     @ java.net.socketoutputstream.write(socketoutputstream.java:136)     @ org.apache.coyote.http11.internaloutputbuffer.realwritebytes(internaloutputbuffer.java:737)     @ org.apache.tomcat.util.buf.bytechunk.flushbuffer(bytechunk.java:434)     @ org.apache.coyote.http11.internaloutputbuffer.flush(internaloutputbuffer.java:299)     @ org.apache.coyote.http11.http11processor.action(http11processor.java:963)     @ org.apache.coyote.response.action(response.java:183)     @ org.apache.catalina.connector.outputbuffer.doflush(outputbuffer.java:314)     ... 20 more  [blazeds]23:18:13.689 [debug] streaming thread 'http-8400-1' endpoint id 'my-streaming-amf' releasing connection , returning request handler pool. [blazeds]23:18:13.689 [info] number of streaming clients flexsession id '5bc5e8d604a361bca673b05ac624ccc1' 0. [blazeds]23:18:13.689 [debug] number of streaming clients endpoint id 'my-streaming-amf' 0. 

    at stage, subscriptions still shown on activemq web admin interface being active.

  2. killing blazeds (more precisely, tomcat server hosts it) kill -9 console makes activemq realize "proxy jms client" gone , becomes offline on activemq web admin interface. made me conclude blazeds keeping proxy jms client alive explicitly since kill -9 gives no chance blazeds unsubscribe client still becomes offline in activemq.

so, question once again: can here ensure blazeds makes "proxy jms client" offline in activemq when real flex counterpart terminates unexpectedly? bug in blazeds or missing hidden configuration setting make work?

version information: blazeds 4.0, activemq 5.5.0, both freshly downloaded today. i'm using tomcat server in blazeds turnkey activemq installed separately because blazeds turnkey ships activemq 4.1.1 only. way, version of activemq has same issue.

the problem there no way blazeds detect flex client shutdown, have implement own mechanism - suggestion use heart beat implemented messaging. if no message received client after time interval can assume flex client gone , disconnect (or can use session timeout mechanism on server, , disconnect on session expire).

what have seen (the exception caught when streaming channel closed) not enough 100% sure flex client gone. streaming implemented using http connection kept open forever (used send server messages) , periodic http post calls (initiated client send messages). in networks firewall can decide kill http connection after couple of seconds , receive same error 1 posted. however, not mean flex client killed - flex client can use fallback strategy , switch short/long polling in case. bug if blazeds automatically jms disconnect in case.


Comments

Popular posts from this blog

c# - SharpSVN - How to get the previous revision? -

c++ - Is it possible to compile a VST on linux? -

url - Querystring manipulation of email Address in PHP -