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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
