Customize message id

[jxz024000]

Hello,

I want to log the message id after sending each message. The message id will
be used to report ticket to Azure team for them to troubleshooting. My
project currently use Spring JmsTemplate as sender client. I first thought I
may be able to set it in the Message object used by JmsTemplate
(message.setJMSMessageID(some string here)). But when I debugged into the
qpid client. I found it always set it own produced message id in
JmsSession.send() method (as shown below). Is there a good way I can override this behavior?

            long messageSequence = producer.getNextMessageSequence();
            Object messageId = null;
            if (!disableMsgId) {
                messageId =
producer.getMessageIDBuilder().createMessageID(producer.getProducerId().toString(),
messageSequence);
            }

If there is no good way to provide my own message id to qpid, then the next thing I'm trying to find out is if I can get a hold of the Message object and cast it to AmqpJmsMessageFacade and get the message id from properties. But so far JmsTemplate class only provide entry to access the Message object before it dispatches it to qpid. I don't find a good way to get hold of Message object after qpid set message id and send the message.

What about enable some debug mode and let qpid log the message id? I have tried enable org.apache.qpid.jms at debug level. But I only see qpid log the message id for consumer, but not producer.

Any other approach?

Thanks,


--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Timothy Bish]

On 1/11/21 2:36 PM, jxz024000 wrote:
> Hello,
>
> I want to log the message id after sending each message. The message id will
> be used to report ticket to Azure team for them to troubleshooting. My
> project currently use Spring JmsTemplate as sender client. I first thought I
> may be able to set it in the Message object used by JmsTemplate
> (message.setJMSMessageID(some string here)). But when I debugged into the
> qpid client. I found it always set it own produced message id in
> JmsSession.send() method. Is there a good way I can override this behavior?

The JMS Specification defines how the MessageProducer is the responsible
party in assigning the message id to the message when it is sent.  The
Qpid JMS client does offer some minor customization of the type of
message Id values it will send but does not provide a means of allowing
a user defined message Id value in order to preserve JMS specification
compliant behavior and AMQP compliant message ID types.

You should instead look to using a message property to carry and
business application specific values as you have control of the property
names and values (within the allowed JMS defined types).

> Thanks,
>
>
>              long messageSequence = producer.getNextMessageSequence();
>              Object messageId = null;
>              if (!disableMsgId) {
>                  messageId =
> producer.getMessageIDBuilder().createMessageID(producer.getProducerId().toString(),
> messageSequence);
>              }
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Tim Bish


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jxz024000]

Hi Tim,

Thanks for the answer. We do set a correlation id in message header
message.setJMSCorrelationID(some uuid); But the problem is that on Azure
Service Bus server side, the engineers can't use this correlation id to
locate the log related to the message. Azure ServiceBus support person told
me they use message id and enqueued time to find the corresponding log in
the server side.

Thanks,
Jia



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Robbie Gemmell]

As Tim said the client is operating in the manner JMS mandates,
whereby msg.setJMSMessageID(..) isnt for use by applications but
rather by JMS clients, and the client sets a message ID upon send(),
with the value available after the send call returns, using
msg.getJMSMessageID().

There are some URI options to tweak the precise ID behaviour as Tim
touched on, which can also be leveraged via code. If you desperate to
control the values more explicitly, I'll note this thread:
https://lists.apache.org/thread.html/rb15c0d2bbe70e736585c2379a3a1c1af6c935d16d6eef294c5a92f2a%40%3Cusers.qpid.apache.org%3E

On Mon, 11 Jan 2021 at 23:24, jxz024000 <[hidden email]> wrote:

>
> Hi Tim,
>
> Thanks for the answer. We do set a correlation id in message header
> message.setJMSCorrelationID(some uuid); But the problem is that on Azure
> Service Bus server side, the engineers can't use this correlation id to
> locate the log related to the message. Azure ServiceBus support person told
> me they use message id and enqueued time to find the corresponding log in
> the server side.
>
> Thanks,
> Jia
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jxz024000]

Thanks Rob. The ThreadLocal idea from the referred link helps me to solved
the issue. Basically I use a ThreadLocal object to store the message before
send() is called and then use msg.getJMSMessageID() to log the id after
send() is called. This works perfect for me as I really don't need to
customize id if I can simply log it.

One more question, I noticed I do have the message id logged as well by qpid
when I turned on the DEBUG level on qpid jms. I initially thought the log is
from the consumer when it receives the message from the broker. But with the
application code logging the message id, it looks like the AmqpConsumer log
is actually called by the sender to log the message id?

2021-01-12 16:45:21,523 [AmqpProvider
:(1):[amqps://sbnagsrdv2usw.servicebus.windows.net:-1]] DEBUG  
o.a.qpid.jms.provider.amqp.AmqpConsumer - Dispatching received message:
JmsInboundMessageDispatch { sequence = 1, messageId =
ID:a1feef5c-2e14-4722-b880-9366571b990f:2:1:1-1, consumerId =
ID:5eec83ba-325e-413b-b00f-969ab30f3e5d:1:1:1 }
2021-01-12 16:45:36,790 DEBUG c.p.c.a.i.messaging.jms.JmsMessageSender -
MessageId: 'ID:a1feef5c-2e14-4722-b880-9366571b990f:2:1:1-1'



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Robbie Gemmell]

On Tue, 12 Jan 2021 at 17:01, jxz024000 <[hidden email]> wrote:
>
> Thanks Rob. The ThreadLocal idea from the referred link helps me to solved
> the issue. Basically I use a ThreadLocal object to store the message before
> send() is called and then use msg.getJMSMessageID() to log the id after
> send() is called. This works perfect for me as I really don't need to
> customize id if I can simply log it.
>

I dont really follow this. The ThreadLocal was a specific hack to
provide a particular ID value for a custom ID generator to return once
it was called on that thread by the client during send. If you already
have the message object, and only want to get and log the
client-provided ID after sending, and not customise the ID in any way,
then you should already be able to do that simply without any hoops.
What is the ThreadLocal being used for?

> One more question, I noticed I do have the message id logged as well by qpid
> when I turned on the DEBUG level on qpid jms. I initially thought the log is
> from the consumer when it receives the message from the broker. But with the
> application code logging the message id, it looks like the AmqpConsumer log
> is actually called by the sender to log the message id?
>
> 2021-01-12 16:45:21,523 [AmqpProvider
> :(1):[amqps://sbnagsrdv2usw.servicebus.windows.net:-1]] DEBUG
> o.a.qpid.jms.provider.amqp.AmqpConsumer - Dispatching received message:
> JmsInboundMessageDispatch { sequence = 1, messageId =
> ID:a1feef5c-2e14-4722-b880-9366571b990f:2:1:1-1, consumerId =
> ID:5eec83ba-325e-413b-b00f-969ab30f3e5d:1:1:1 }
> 2021-01-12 16:45:36,790 DEBUG c.p.c.a.i.messaging.jms.JmsMessageSender -
> MessageId: 'ID:a1feef5c-2e14-4722-b880-9366571b990f:2:1:1-1'
>

That first log is indeed a client log from a receiver with details of
what it is handing on. The JmsInboundMessageDispatch object carries
the decoded received AMQP message further into the client for handling
and eventually delivery to applications, and some of its details are
logged at debug as that occurs, including its message id.

The second log is something from your application code, so I can't
really say much there, having no knowledge what it does. If you
receive a message and e.g log the details and then send it or
something, it will of course match what the consumer got before the
next send.

>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jxz024000]

Sorry for some confusion. The reason I use ThreadLocal is that with Spring
JmsTemplate API I can only access the message object before it sends to the
qpid send() method. This means the message object doesn't have message Id
set by producer yet. So by using ThreadLocal to store the message object
before send() call, I can get it later afterwards and log the message id. It
feels like a hack. But it is purely due to the lacking of post send access
to message object in JmsTemplate API.

For the log, the first log entry is from qpid, the second entry is from my
application code which I just implemented using ThreadLocal to log message
Id. My question is for the first log entry from qpid. I have application log
to write something right before sending the message, and then log the
message Id right after sending the message. But between these two log
entries, I found the one from qpid JmsConsumer to log the message id as you
seen as the first log entry in the post. What I was confused is whether the
first log entry from sender part or from receiver part. But I think I now
get it. It's just a timing situation. The consumer thread happens to receive
the message before the sender thread log the message id.





--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]