How can I Send/Receive a message from Azure Service Bus from Qpid JMS (qpid-jms-client-0.11.1.jar)?

偶尔善良 提交于 2019-12-06 05:20:56

The newer client enables AMQP heartbeating/idle-timeout by default, while the older client did not. The client sets a default 60second timeout, and in turn this means it requests a 30sec (30000ms) idle-timeout value in its AMQP Open frame when connecting to the server, in accordance with the specifications defined behaviour (where peers advertise half their actual timeout to help avoid spurious timeouts).

ServiceBus is refusing the 30000ms Open frame value, and indicating it needs a value of at least 60000ms (or presumably also 0, which means it is disabled). To acheive this you will need to configure the client to have its timeout set to at least 120000ms, which will result in the required minimum 60000ms Open frame idle-timeout value ServiceBus is mandating (or again, perhaps disable the clients timeout handling by setting it to 0).

You can do this using the "amqp.idleTimeout" URI option, as per http://qpid.apache.org/releases/qpid-jms-0.11.1/docs/index.html#amqp-configuration-options

EDIT: I see you figured that out at the same time I was typing my answer.

The new exception is from ServiceBus saying you arent authorized to do something you are trying. It should be easy enough to catch the exception at its source and determine what.

Your URI seems fine (though I assume your username isnt actually 'somePolicy' and the double connectionfactory.myFactoryLookup = connectionfactory.myFactoryLookup = at the start is a c&p error). I haven't used the client with ServiceBus personally, but I've seen questions from various folks that have, so I'm not aware of a particular issue outright stopping them working together.

Paul Smith

I ran into the same security issue referred to above and spent a while tracking it down so for anyone else my issue was caused by the key value specified in the user.password query param containing the + character.

There is usually an = on the end of the value which I encoded as %3D in the string and I encoded the + as %2B however if you put a breakpoint at the point the ConnectionFactory is instantiated and look at the password attribute you will see that the = is correctly unencoded but the + has been stripped and is a SPACE hence the unauthorized access issues.

My workaround was just to regenerate the primary key in Azure so it didn't have a + in it (yuk) but it worked. Possibly a bug in the AQPID libs.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!