From: Dean A. <de...@av...> - 2007-06-29 19:43:35
|
First, thanks for beta 1 release. I noticed while looking through the code that there can be only one exception listener. The spec allows multiple listeners to be registered. This is an easy fix. I noticed this while thinking about handling the case of a cached connection in a web-app, and restarting the connection (after a jms server restart), losing (cached) sessions, etc. I started thinking about that because I was thinking of using a temporary queue in a reply-to in a web-app, and the temporary topic only lasts as long as the connection and session, so 1) connections and sessions have to be cached. 2) one needs to handle the case of a jms server restart. I think a container tomcat maybe shouldn't register an exception handler, either, though I might be able to make it work anyway... Does anyone have any experiences they'd like to share? EJB is not a happy choice. BTW, I also noticed that tcps connections don't work with an external jndi rmi registry, unless you hard code a property for the new trust store. Seems like something for SSL in the client doesn't get initialized properly when using an external jndi provider. Server works fine. Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 |
From: Tim A. <tm...@ne...> - 2007-07-01 23:44:23
|
Dean Anderson wrote: > First, thanks for beta 1 release. > > I noticed while looking through the code that there can be only one > exception listener. The spec allows multiple listeners to be registered. > This is an easy fix. > Not sure what you mean. There can be one exception listener per javax.jms.Connection instance. > I noticed this while thinking about handling the case of a cached > connection in a web-app, and restarting the connection (after a jms > server restart), losing (cached) sessions, etc. > > I started thinking about that because I was thinking of using a > temporary queue in a reply-to in a web-app, and the temporary topic only > lasts as long as the connection and session, so 1) connections and > sessions have to be cached. 2) one needs to handle the case of a jms > server restart. > You can also attempt to re-establish the connection if the publish/subscribe fails. When caching sessions, you just need to ensure that you synchronize access so only one thread as session at a time. > I think a container tomcat maybe shouldn't register an exception > handler, either, though I might be able to make it work anyway... Does > anyone have any experiences they'd like to share? EJB is not a happy > choice. > > > BTW, I also noticed that tcps connections don't work with an external > jndi rmi registry, unless you hard code a property for the new trust > store. Seems like something for SSL in the client doesn't get > initialized properly when using an external jndi provider. Server works > fine. > Haven't tried. Typically you wouldn't use an rmi registry and tcps, as the rmi registry is not secure. You are better off using the embedded JNDI provider. > Thanks, > > --Dean > -Tim |
From: Dean A. <de...@av...> - 2007-07-02 20:29:15
|
On Mon, 2 Jul 2007, Tim Anderson wrote: > Dean Anderson wrote: > > First, thanks for beta 1 release. > > > > I noticed while looking through the code that there can be only one > > exception listener. The spec allows multiple listeners to be registered. > > This is an easy fix. > > > Not sure what you mean. There can be one exception listener per > javax.jms.Connection instance. Hmm. Maybe I misunderstood. I'm going off the old Oreilly Java Message Service book, which says page 123: "It is the responsibility of the JMS provider to call the onException() method of all registered ExceptionListeners after making reasonable attempts to reestablish the connection automatically" I take the plural and 'all' to mean that more than one thing (presumably each sesssion) can register an ExceptionListener on a connection. OpenJMS only allows one exceptionListener. > You can also attempt to re-establish the connection if the > publish/subscribe fails. When caching sessions, you just need to > ensure that you synchronize access so only one thread as session at a > time. Ok. Thanks. Is it safe to assume that in a web container, only one thread at a time works on a given web request? So, if I put the JMS session object in the web-container session store, is it safe to assume there is only one thread that handles each web request for a given (web)session? Sorry if this is web-specific, but any experiences with this is appreciated. > > BTW, I also noticed that tcps connections don't work with an external > > jndi rmi registry, unless you hard code a property for the new trust > > store. Seems like something for SSL in the client doesn't get > > initialized properly when using an external jndi provider. Server works > > fine. > > > Haven't tried. Typically you wouldn't use an rmi registry and tcps, as > the rmi registry is not secure. You are better off using the embedded > JNDI provider. Oops. Good point on the RMI registry--Must make a note of that. However, the initialization part should _still_ work. Something else might need initialization... Thanks! --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 |
From: Tim A. <tm...@ne...> - 2007-07-02 23:55:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Dean Anderson wrote: <blockquote cite="mid...@ci..." type="cite"> <pre wrap="">On Mon, 2 Jul 2007, Tim Anderson wrote: </pre> <blockquote type="cite"> <pre wrap="">Dean Anderson wrote: </pre> <blockquote type="cite"> <pre wrap="">First, thanks for beta 1 release. I noticed while looking through the code that there can be only one exception listener. The spec allows multiple listeners to be registered. This is an easy fix. </pre> </blockquote> <pre wrap="">Not sure what you mean. There can be one exception listener per javax.jms.Connection instance. </pre> </blockquote> <pre wrap=""><!----> Hmm. Maybe I misunderstood. I'm going off the old Oreilly Java Message Service book, which says page 123: "It is the responsibility of the JMS provider to call the onException() method of all registered ExceptionListeners after making reasonable attempts to reestablish the connection automatically" I take the plural and 'all' to mean that more than one thing (presumably each sesssion) can register an ExceptionListener on a connection. OpenJMS only allows one exceptionListener. </pre> </blockquote> No. The Connection interface takes a single exception listener via the <br> setExceptionListener(ExceptionListener listener) method. You're book is just saying<br> that each Connection instance needs to notify its associated listener when the connection is lost.<br> <blockquote cite="mid...@ci..." type="cite"> <blockquote type="cite"> <pre wrap="">You can also attempt to re-establish the connection if the publish/subscribe fails. When caching sessions, you just need to ensure that you synchronize access so only one thread as session at a time. </pre> </blockquote> <pre wrap=""><!----> Ok. Thanks. Is it safe to assume that in a web container, only one thread at a time works on a given web request? So, if I put the JMS session object in the web-container session store, is it safe to assume there is only one thread that handles each web request for a given (web)session? Sorry if this is web-specific, but any experiences with this is appreciated. </pre> </blockquote> A client can submit simultaneous requests so you still need to synchronize.<br> <blockquote cite="mid...@ci..." type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">BTW, I also noticed that tcps connections don't work with an external jndi rmi registry, unless you hard code a property for the new trust store. Seems like something for SSL in the client doesn't get initialized properly when using an external jndi provider. Server works fine. </pre> </blockquote> </blockquote> <blockquote type="cite"> <pre wrap="">Haven't tried. Typically you wouldn't use an rmi registry and tcps, as the rmi registry is not secure. You are better off using the embedded JNDI provider. </pre> </blockquote> <pre wrap=""><!----> Oops. Good point on the RMI registry--Must make a note of that. However, the initialization part should _still_ work. Something else might need initialization... Thanks! --Dean </pre> </blockquote> Not sure what you mean. When using the RMI registry, you need to connect to it using the rmi protocol.<br> If the tcps connector is also configured, ConnectionFactory instances bound in the registry will connect<br> to the server via tcps; you need to configure the tcps properties as per <a class="moz-txt-link-freetext" href="http://openjms.sourceforge.net/usersguide/tcps.html">http://openjms.sourceforge.net/usersguide/tcps.html</a><br> <br> -Tim<br> <br> </body> </html> |
From: Dean A. <de...@av...> - 2007-07-03 13:41:17
|
On Tue, 3 Jul 2007, Tim Anderson wrote: > Not sure what you mean. When using the RMI registry, you need to > connect to it using the rmi protocol. If the tcps connector is also > configured, ConnectionFactory instances bound in the registry will > connect to the server via tcps; you need to configure the tcps > properties as per http://openjms.sourceforge.net/usersguide/tcps.html Yes. Did that: (I think): I had these properties: factoryName=ConnectionFactory destName=queue2 java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory java.naming.provider.url=rmi://localhost:1099 username=test1 password=<deleted> org.exolab.jms.net.tcps.keyStore=client.keystore org.exolab.jms.net.tcps.keyStorePassword=<deleted> org.exolab.jms.net.tcps.trustStore=client.keystore org.exolab.jms.net.tcps.trustStorePassword=<deleted> These properties were passed to the Receiver.java program (slightly modified to load a properties file): context = new InitialContext(appProps); // look up the ConnectionFactory factory = (ConnectionFactory) context.lookup(appProps.getProperty("factoryName")); // look up the Destination dest = (Destination) context.lookup(appProps.getProperty("destName")); // create the connection connection = factory.createConnection(appProps.getProperty("username"), appProps.getProperty("password")); //connection = factory.createConnection(); // create the session session = connection.createSession( false, Session.AUTO_ACKNOWLEDGE); // create the receiver receiver = session.createConsumer(dest); // start the connection, to enable message receipt connection.start(); This works, but only if -Djavax.net.ssl.trustStore=client.keystore is added to run.sh. Otherwise, you get an unknown_certificate error. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 |