Details
-
Bug
-
Status: Reopened
-
Major
-
Resolution: Unresolved
-
qpid-java-broker-7.1.3
-
None
-
None
Description
When peer sends a subsequent attach for already active link (the link name is the same but handle is different), the broker ends session with internal error ("Endpoint is already registered with session.").
This behaviour looks not spec complaint to me for the following reasons:
- it is not a broker internal error
- the error is related to the link rather than session. Thus, session ending looks like too radical action
IMHO, the broker can potentially utilize the following behaviour to handle this situation
- apply link stealing functionality (detach active link and attach new one)
- reply with attach followed by detach with error "amqp:link:detach-forced"
The latter looks like more appropriate behaviour to me. Though, we use the former to steal link by a different session.
Here is relevant broker logs for the issue
o.a.q.s.p.frame RECV[/127.0.0.1:41796|1] : Begin{nextOutgoingId=0,incomingWindow=0,outgoingWindow=0} o.a.q.s.p.frame SEND[/127.0.0.1:41796|0] : Begin{remoteChannel=1,nextOutgoingId=0,incomingWindow=8192,outgoingWindow=2048} o.a.q.s.p.frame RECV[/127.0.0.1:41796|1] : Attach{name=testLink,handle=0,role=sender,source=Source{},target=Target{},initialDeliveryCount=0} o.a.q.s.p.frame SEND[/127.0.0.1:41796|0] : Attach{name=testLink,handle=0,role=receiver,source=Source{},target=Target{durable=none,capabilities=[DELAYED_DELIVERY]},unsettled={},maxMessageSize=104857600,offeredCapabilities=[DELAYED_DELIVERY],properties={}} o.a.q.s.p.frame SEND[/127.0.0.1:41796|0] : Flow{nextIncomingId=0,incomingWindow=8192,nextOutgoingId=0,outgoingWindow=2048,handle=0,deliveryCount=0,linkCredit=20000,echo=false} o.a.q.s.p.frame RECV[/127.0.0.1:41796|1] : Attach{name=testLink,handle=1,role=sender,source=Source{},target=Target{},initialDeliveryCount=0} o.a.q.s.p.frame SEND[/127.0.0.1:41796|0] : End{error=Error{condition=internal-error,description=Endpoint is already registered with session.}}