[RESULT][VOTE] Release Qpid Broker-J 7.1.11
There were 3 binding +1 votes and 1 non-binding +1 community vote. The vote has passed. The voting thread can be found here: https://lists.apache.org/thread.html/r0e9ae619f541e2cad2c05ae3940ee07f7603f570a55f5b437ad53190%40%3Cusers.qpid.apache.org%3E I will add the release bundles to the dist release repo and promote the maven artefacts from staging repo into maven central. The website will be updated once the artefacts have had time to sync to the mirrors and maven central. Kind Regards, Alex - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[RESULT][VOTE] Release Qpid Broker-J 8.0.3
There were 3 binding +1 votes and 1 non-binding +1 community vote. The vote has passed. The voting thread can be found here: https://lists.apache.org/thread.html/rb5ff22cecae27e5baf8b25a0f082d1a218035d106f8d73deba09310a%40%3Cusers.qpid.apache.org%3E I will add the archives to the dist release repo and release the maven staging repo shortly. The website will be updated once the artefacts have had time to sync to the mirrors and maven central. Kind Regards, Alex - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Customize message id
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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Customize message id
On Tue, 12 Jan 2021 at 17:01, jxz024000 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: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Customize message id
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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Customize message id
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 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: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Cannot connect to Azure IoT Hub with Qpid JMS client
It's always been my understanding that the use of CBS was optional.
Certainly, none of the Microsoft documentation I've seen around using
the JMS client (with Service Bus) refers to it that I can recall.
In looking at the original code from the first mail again, I see its
included 'Azure connection string'
("HostName=.azure-devices.net;DeviceId=device001;SharedAccessKey=")
only contains a SharedAccessKey value. From some searching I expect
there also needs to be a SharedAccessKeyName value too. These are both
seemingly used and passed when creating the connection from the
factory, effectively passed as the user/pass values:
"Connection connection = cf.createConnection(csb.getSasKeyName(),
csb.getSasKey());"
So if the getSasKeyName() return value is null/empty, then the client
will likely only be able to use the ANONYMOUS SASL mech(unless doing
TLS client certificate auth), assuming it is actually offered by the
server, which in this case I expect it would be since ANONYMOUS is a
key route CBS is used via. So I expect the client was able to connect
as I said before, but only anonymously as that was offered and it had
insufficient details to do anything else, but was as result then
unable to complete things such as creating the MessageProducer since
it was only 'anonymously authenticated' and so was denied
authorization having not done anything else like CBS usage.
Various links:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-java-how-to-use-jms-api-amqp
https://docs.microsoft.com/en-us/azure/service-bus-messaging/how-to-use-java-message-service-20
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-create-namespace-portal#get-the-connection-string
https://github.com/Azure/azure-service-bus-java/blob/2.0.0/azure-servicebus/src/main/java/com/microsoft/azure/servicebus/primitives/ConnectionStringBuilder.java#L32-L33
On Mon, 11 Jan 2021 at 20:14, reifujin wrote:
>
> What Robbie says is correct, Azure uses claims-based authorization. Part of
> the magic that the IoT SDK does is create a session to the $cbs node with
> the correct payload. The information is here:
> https://docs.microsoft.com/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization
>
> A pointer to where the IoT client library does this magic is here:
> https://github.com/Azure/azure-iot-sdk-java/blob/master/device/iot-device-client/src/main/java/com/microsoft/azure/sdk/iot/device/transport/amqps/AmqpsIotHubConnection.java#L247
>
> Cheers,
> Connie
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
