Bug in JMSProducer? Settings retained in JMSContext if retained in ApplicationContext

[genman]

I'm not sure this is a spec thing, but in WildFly I observe the following:

1. Obtain a JMSContext using @Inject into an @ApplicationScoped bean.

2. Create a JMSProducer using JMSContext.createProducer()

3. Set the scheduled delivery time of a message

4. Send the message.

For the second call to send the message, the scheduled delivery time is used once again, although in a totally different thread. Which is totally mysterious.

The work around is something like this:

@RequestScoped
class JMSProducerProducer {


    @Inject
    JMSContext context;

    @Produces @RequestScoped JMSProducer getProducer() {
        JMSProducer producer = context.createProducer();
        producer.clearProperties();
        producer.setDeliveryDelay(0);
        producer.setTimeToLive(0);
        return producer;
    }

}

I'm guessing the code is wrong in that the create method. Perhaps it should simply create a new instance each time?

public class HornetQJMSContext implements JMSContext
{
   @Override
   public JMSProducer createProducer()
   {
      checkSession();
      try
      {
         return new HornetQJMSProducer(this, getInnerProducer());
      }
      catch (JMSException e)
      {
         throw JmsExceptionUtils.convertToRuntimeException(e);
      }
   }

   private synchronized MessageProducer getInnerProducer() throws JMSException
   {
      if (innerProducer == null)
      {
         innerProducer = session.createProducer(null);
      }

      return innerProducer;
   }

For example:

diff --git a/hornetq-jms-client/src/main/java/org/hornetq/jms/client/HornetQJMSContext.java b/hornetq-jms-client/src/main/java/org/hornetq/jms/client/HornetQJMSContext.java
index 27b8e2d..f3c51c5 100644
--- a/hornetq-jms-client/src/main/java/org/hornetq/jms/client/HornetQJMSContext.java
+++ b/hornetq-jms-client/src/main/java/org/hornetq/jms/client/HornetQJMSContext.java
@@ -58,7 +58,6 @@
    private final HornetQConnectionForContext connection;
    private Session session;
    private boolean autoStart = HornetQJMSContext.DEFAULT_AUTO_START;
-   private MessageProducer innerProducer;
    private boolean xa;
    private boolean closed;

@@ -112,7 +111,7 @@ public JMSProducer createProducer()
       checkSession();
       try
       {
-         return new HornetQJMSProducer(this, getInnerProducer());
+         return new HornetQJMSProducer(this, session.createProducer(null));
       }
       catch (JMSException e)
       {
@@ -120,16 +119,6 @@ public JMSProducer createProducer()
       }
    }

-   private synchronized MessageProducer getInnerProducer() throws JMSException
-   {
-      if (innerProducer == null)
-      {
-         innerProducer = session.createProducer(null);
-      }
-
-      return innerProducer;
-   }
-
    /**
     *
     */

[jbertram]

The innerProducer was added on purpose via https://issues.jboss.org/browse/HORNETQ-1293.

[genman]

I'm really confused by this because this code doesn't do what you might expect:

JMSProducer p = JMSContext.createProducer();
p.setTimeToLive(1000);
p.send(...)
JMSProducer p2 = JMSContext.createProducer();
p2.send(...) // time to live is set to 1000 here!

What's the point of having two producers here? The JavaDoc says "new producer" but in fact the settings are carried over from the old producer object.

I'm having a hard time understanding from the bug/commit why the change was made, e.g. what part of the spec was HornetQ not following.

It looks like the reference implementation does do the same thing, though, but to me it seems really unintuitive.

[clebert.suconic]

Once you get the Producer created, the producer will always exist on the JMSContext.

That would be the same as doing

Producer x = ...createProducer

x.setProperties(.);

any subsequent usage of the producer will have the same properties.

that is because it would be fairly inefficient to create a new producer per message. on JMS2 users are supposed to be doing this all the time:

jmsContext.createProducer().setProperty().setProperty().send(...);

any further calls on createProducer would return the same property.

And it's difficult for us to know if the producer was reused or not.

Are you using JCA on this example? if that's between different JCA calls than it's a different story, the propducer should have been cleared before returned to the pool.

[clebert.suconic]

I just looked at the implementation.

We create a new HornetQJMSProducer for every call, but there is an inner Producer cached. things like properties are set on that instance you're creating only... things like TTL or other things that were part of the JMS 1.1, it goes towards the inner cached producer.

[genman]

It's hard to say if I'm using JCA or not, I simply use CDI to inject the JMSContext and rely on whatever the container provides me. But I'm not injecting into an EJB but a @ApplicationScoped bean. I was assuming that somehow the container would do the right thing and give me a new pooled JCA instance each time, but it's hard to say what it's doing. I guess I'd have to read through the JBoss source code to know which connection factory is used.

So what you're also saying is JMS 1.1 settings (e.g. TTL) are shared, but message properties aren't? I went through the specs and didn't see this behavior defined anywhere, so I'm thinking it's some sort of omission. At least the spec should note this. I sent a message to the [e-mail] list, but I don't expect to see a response.

[clebert.suconic]

Quite contrary. I did see your message at [e-mail].. I didn't answer you there because i would be duplicating my posts... I'm waiting the spec lead to answer .. probably tomorrow.

The spec implicates a cached producer.. but it's not specified what to do with those properties.  I would expect it being cached if you're using JMS2.

I will wait for the spec.. if he doesn't answer it I will ping him on the same thread.

[genman]

In my particular situation I was using scheduled delivery time. The first message I sent for immediate delivery, the second in an hour or so. Then what happened was every subsequent message was delivered in an hour or so and I thought my application was broken.

I haven't done JMS in a while, but back then you had to use a vendor specific message property to set scheduled delivery time. So ironically, if I had used _HQ_SCHED_DELIVERY, I probably wouldn't have encountered this issue.

[clebert.suconic]

You can still use the Sched_Delivery property

[genman]

So it indeed is a bug. https://issues.jboss.org/browse/HORNETQ-1355