[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609311#comment-16609311
]
Robbie Gemmell commented on DISPATCH-1090:
------------------------------------------
I may be misunderstanding, I don't know the router code, but reading the test
it seems like the change operates only after a message arrives that is
undeliverable? That could prevent a release->send loop forming until the credit
is used in some cases, but it seems like in others it wouldn't be as effective
as it could be?
There is obviously a race here in that even if the drain were performed
immediately when the last receiver went away the sender might already have put
lots of messages in flight using credit it had. However it seems a little odd
potentially leaving the sender with that credit for an unknown amount of time
until they use it to send something. In that regard, its just as likely a large
number of small messages could end up being sent later if they become available
at the sender and end up being sent+released.
One complication might be address-specific links vs anonymous sender links,
though it isn't clear to me whether they are handled any different (again,
don't know the router code). In some ways makes sense, stops them sending lots
to the address, but in other ways could be questionable as the anonymous link
then cant sent to other addresses either.
In any case, I'd perhaps say the tests could do with expanding to ensure credit
is restored at the appropriate time and in the expected amount. Another useful
case to test might be when a new receiver becomes available before the sender
has completed draining after the original receivers went away. Distinct drain
attempts cant really be correlated without allowing them to complete before
then flowing more credit or attempting another drain, and failing to account
for that might leave you thinking a link has credit when it doesnt.
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Version 1.3.0-SNAPSHOT
> (30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
> Reporter: Keith Wall
> Assignee: Ganesh Murthy
> Priority: Major
> Fix For: 1.4.0
>
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
> Protocol trace attached to this issue demonstrates the problem.
> Dispatch Router was configured by the following commands:
> {noformat}
> qdmanage create --type org.apache.qpid.dispatch.connector host=oslo.local
> port=5672 name=artemis-broker role=route-container
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=in connection=artemis-broker
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=out connection=artemis-broker
> qdmanage create --type=org.apache.qpid.dispatch.router.config.address
> pattern=queue waypoint=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
