StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I'm not understanding why in the previous response and discussion there is an assumption that non-durable subscriptions are not portable. Here's a code sample (<a href="http://www.ibm.com/developerworks/websphere/techjournal/0610_woolf/0610_woolf.html" rel="nofollow">download link</a>) of one that is both non-durable and JMS 1.1 compliant.</p> <pre><code>session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE); myDest = (Destination)ctx.lookup(dLookup); MessageConsumer myConsumer = session.createConsumer(myDest); Message inMessage = null; do { inMessage = myConsumer.receive(10000); if( inMessage instanceof TextMessage ) { System.out.println( "\n" + "Got message: "+((TextMessage) inMessage).getText()); } session.commit(); } while ( inMessage != null ); myConsumer.close(); </code></pre> <p>Not only is the subscriber non-durable in the previous example, but it doesn't matter whether it is a topic or a queue that is retrieved from the JNDI lookup. The link above is to an article with working code samples and JNDI objects written for WMQ v6 but which work equally well on WMQ v7 (but with slightly different setup at the QMgr since pub/sub no longer requires a separate broker component).</p> <p>Aside from that, the original responder is correct in that as long as the app conforms to the JMS spec, it should run in any JMS compliant transport. Insomuch as that is true, it does not take into account that differences in the vendor's transport implementation bubble up through the JMS abstraction to impact your code.</p> <p>For example, JMS provides a multi-level exception where the top level is the JMS exception and the next level is the linked exception. It is the linked exception in which the vendor can place vendor-specific error codes. For example, in WMQ you might get a linked exception indicating that the queue is full or a linked exception telling you that the queue is damaged. One of these is transient and retry behavior is appropriate while the other indicates a fatal error. If the app does not understand the errors in the linked exception, it cannot tell the difference.</p> <p>Some apps intended to be portable deal with this by simply treating all exceptions as fatal. They close all objects and connections and reinitialize. I've also seen an approach where the developer gives up all attempts at portability and looks in the linked exceptions for vendor-specific codes. Somewhere between those approaches are shops that have vendor-specific shims or sub-classes that wrap JMS objects so the app can remain portable but still respond appropriately to vendor-specific exceptions.</p> <p>Even assuming that these things are not an issue, it is still important to understand <em>how</em> the vendor has interpreted and implemented the spec. For example, some transports seamlessly fail clients over when a broker fails. Developers might rely on that behavior and omit any reconnect logic from their app. But what if the problem is not the broker but rather is at the network connection at the client? How long will the app hang attempting to fail over and what does the user see? The spec does not address these issues and portability only gets you so far. </p> <p>So by all means understand the spec and write portable code, but also understand the vendor's implementation of the spec and where the boundaries of portability lie with that implementation. In any case, that boundary does not lie between durable and non-durable subscriptions.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload