Bug in openjms 0.7.7 beta 1

[Dean Anderson]

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  



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openjms-developer mailing list
openjms-developer@...
https://lists.sourceforge.net/lists/listinfo/openjms-developer

[Tim Anderson]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openjms-developer mailing list
openjms-developer@...
https://lists.sourceforge.net/lists/listinfo/openjms-developer

[Dean Anderson]

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  



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openjms-developer mailing list
openjms-developer@...
https://lists.sourceforge.net/lists/listinfo/openjms-developer

[Tim Anderson]

Dean Anderson wrote:

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.
  

No. The Connection interface takes a single exception listener via the
setExceptionListener(ExceptionListener listener) method. You're book is just saying
that each Connection instance needs to notify its associated listener when the connection is lost.

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.
  

A client can submit simultaneous requests so you still need to synchronize.

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
  

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

-Tim


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openjms-developer mailing list
openjms-developer@...
https://lists.sourceforge.net/lists/listinfo/openjms-developer

[Dean Anderson]

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  



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openjms-developer mailing list
openjms-developer@...
https://lists.sourceforge.net/lists/listinfo/openjms-developer