Discussion:
[openjms-developer] Bug in openjms 0.7.7 beta 1
Dean Anderson
2007-06-29 19:43:15 UTC
Permalink
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
Tim Anderson
2007-07-01 23:44:11 UTC
Permalink
Post by 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.
Not sure what you mean. There can be one exception listener per
javax.jms.Connection instance.
Post by Dean Anderson
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.
Post by Dean Anderson
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.
Post by Dean Anderson
Thanks,
--Dean
-Tim
Dean Anderson
2007-07-02 20:28:54 UTC
Permalink
Post by Tim Anderson
Post by 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.
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.
Post by Tim Anderson
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.
Post by Tim Anderson
Post by Dean Anderson
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
Tim Anderson
2007-07-02 23:54:56 UTC
Permalink
<!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="midPine.LNX.4.44.0707021555270.11071-***@citation2.av8.net"
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="midPine.LNX.4.44.0707021555270.11071-***@citation2.av8.net"
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="midPine.LNX.4.44.0707021555270.11071-***@citation2.av8.net"
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>
Dean Anderson
2007-07-03 13:40:57 UTC
Permalink
Post by Tim Anderson
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
Loading...