Expected behavior when connecting to an EXCLUSIVE CONNECTION queue

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Expected behavior when connecting to an EXCLUSIVE CONNECTION queue

Igor Natanzon
What would expected behavior be at the JMS client when I am attempting to
connect to an EXCLUSIVE CONNECTION queue and the connection already exists?

What happens in my application is the following:
1. Connection tries to establish, and the session shows up in Connections
view of Web Console.
2. The connection is rejected, as seen in the log:
2019-06-14 15:43:05,782|DEBUG|S-0024|o.a.q.j.p.f.FailoverProvider|Executing
Failover Task: create -> JmsSessionInfo {
FIXHA:UT:2402e806-1297-43e0-b41a-e5b0594371e6:23:1 } (2)
2019-06-14 15:43:05,797|DEBUG|S-0024|o.a.q.j.p.f.FailoverProvider|Executing
Failover Task: create -> JmsSessionInfo {
FIXHA:UT:2402e806-1297-43e0-b41a-e5b0594371e6:23:2 } (3)
2019-06-14
15:43:05,822|DEBUG|Thread-131|o.a.q.j.p.f.FailoverProvider|Executing
Failover Task: create -> JmsConsumerInfo: {
FIXHA:UT:233c7a42-7ee4-492b-8066-bc577c731c97:22:2:1, destination = QUEUE1
} (4)
2019-06-14 15:43:05,836|WARN |AmqpProvider
:(238):[amqp://node2:5672]|o.a.q.j.p.a.b.AmqpResourceBuilder|Open of
resource:(JmsConsumerInfo: {
FIXHA:UT:233c7a42-7ee4-492b-8066-bc577c731c97:22:2:1, destination = QUEUE1
}) failed: Cannot add an exclusive consumer to the destination as there is
an incompatible exclusivity policy [condition = amqp:resource-locked]
2019-06-14
15:43:37,484|DEBUG|S-0021|o.a.q.j.p.f.FailoverProvider|Initiating initial
connection attempt task

3. The initial connection still works fine, and new/rejected connection
fails to attach a consumer, as expected.  However the connection still
exists, but is now useless. If I attempt to drop it using Web Console it
just comes back up due to failover reconnect settings.
4. I can send messages to and shut down the original client without issues,
but the rejected one is just stuck, until i kill the client.
5. The client never gets exceptions or any alerts, and simply gets blocked
during that connection attempt.

I suspect there are some settings I can enable in the connection factory to
prevent this behavior (I'd rather the rejected client exited or errored
out, instead of getting stuck, or at least successfully connect once queue
lock is released).

This is the connection factory setting:
connectionfactory.FIX_TEST =
failover:(amqp://node1:5672,amqp://node2:5672,amqp://node3:5672)?failover.initialReconnectDelay=100&failover.reconnectDelay=100&jms.connectionIDPrefix=FIXHA:UT:&jms.prefetchPolicy.all=100&failover.nested.amqp.vhost=FIX_VHNG

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Expected behavior when connecting to an EXCLUSIVE CONNECTION queue

Robbie Gemmell
Administrator
The snippet in '2' appears to show a connection(+internal session) and
session being established successfully, then a consumer failing to be
established over it. After a period it then appears to show the start
of a new Connection creation.

The consumer creation failing after connection wouldnt invalidate that
connection, just fail to create the consumer on it. If such a
connection were not closed and just left, it would indeed sit there
and reconnect given the configuration used requests that. It wouldnt
establish a consumer on reconnect since it failed to be created.

If the consumer were created and the connection drops or is severed in
most ways then the client will try to restablish the connection as
configured and also e.g an open consumer on it, and at this point it
would class most failures (not e.g. a security exception) to
reestablish a consumer as a failure to reestablish the connection and
open its resources as before the drop, and so will try the whole
reconnection again (though "jms.closeLinksThatFailOnReconnect=true" in
the URI can influence that and just cause the consumer recreation to
fail rather than the reconnect as a whole).

Robbie

On Fri, 14 Jun 2019 at 21:01, Igor Natanzon <[hidden email]> wrote:

>
> What would expected behavior be at the JMS client when I am attempting to
> connect to an EXCLUSIVE CONNECTION queue and the connection already exists?
>
> What happens in my application is the following:
> 1. Connection tries to establish, and the session shows up in Connections
> view of Web Console.
> 2. The connection is rejected, as seen in the log:
> 2019-06-14 15:43:05,782|DEBUG|S-0024|o.a.q.j.p.f.FailoverProvider|Executing
> Failover Task: create -> JmsSessionInfo {
> FIXHA:UT:2402e806-1297-43e0-b41a-e5b0594371e6:23:1 } (2)
> 2019-06-14 15:43:05,797|DEBUG|S-0024|o.a.q.j.p.f.FailoverProvider|Executing
> Failover Task: create -> JmsSessionInfo {
> FIXHA:UT:2402e806-1297-43e0-b41a-e5b0594371e6:23:2 } (3)
> 2019-06-14
> 15:43:05,822|DEBUG|Thread-131|o.a.q.j.p.f.FailoverProvider|Executing
> Failover Task: create -> JmsConsumerInfo: {
> FIXHA:UT:233c7a42-7ee4-492b-8066-bc577c731c97:22:2:1, destination = QUEUE1
> } (4)
> 2019-06-14 15:43:05,836|WARN |AmqpProvider
> :(238):[amqp://node2:5672]|o.a.q.j.p.a.b.AmqpResourceBuilder|Open of
> resource:(JmsConsumerInfo: {
> FIXHA:UT:233c7a42-7ee4-492b-8066-bc577c731c97:22:2:1, destination = QUEUE1
> }) failed: Cannot add an exclusive consumer to the destination as there is
> an incompatible exclusivity policy [condition = amqp:resource-locked]
> 2019-06-14
> 15:43:37,484|DEBUG|S-0021|o.a.q.j.p.f.FailoverProvider|Initiating initial
> connection attempt task
>
> 3. The initial connection still works fine, and new/rejected connection
> fails to attach a consumer, as expected.  However the connection still
> exists, but is now useless. If I attempt to drop it using Web Console it
> just comes back up due to failover reconnect settings.
> 4. I can send messages to and shut down the original client without issues,
> but the rejected one is just stuck, until i kill the client.
> 5. The client never gets exceptions or any alerts, and simply gets blocked
> during that connection attempt.
>
> I suspect there are some settings I can enable in the connection factory to
> prevent this behavior (I'd rather the rejected client exited or errored
> out, instead of getting stuck, or at least successfully connect once queue
> lock is released).
>
> This is the connection factory setting:
> connectionfactory.FIX_TEST =
> failover:(amqp://node1:5672,amqp://node2:5672,amqp://node3:5672)?failover.initialReconnectDelay=100&failover.reconnectDelay=100&jms.connectionIDPrefix=FIXHA:UT:&jms.prefetchPolicy.all=100&failover.nested.amqp.vhost=FIX_VHNG
>
> Thanks!

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