[ 
https://issues.apache.org/jira/browse/PROTON-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321035#comment-15321035
 ] 

Alan Conway commented on PROTON-1227:
-------------------------------------

I can reproduce it. An interesting one. All the Send methods block for credit 
to avoid unbounded local buffering - that is deliberate and important "good 
practice" for Go. Most AMQP brokers will either give you credit or close your 
attach with a "no such address" error. However for an unsubscribed address, 
dispatch will simply not give you any credit until there are subscribers - it 
is not an error. So even with AtMostOnce or SendForget() the Go API will block 
forever waiting for credit, which is not what you expect.

I need to think about this! At the very least it needs better documentation and 
it might need a change in behavior. You can do what you want with 
SendForgetTimeout() with a short timeout but there might be a better solution, 
forcing the user to choose a timeout is fragile.

> Go Client cannot send message in fire-and-forget mode
> -----------------------------------------------------
>
>                 Key: PROTON-1227
>                 URL: https://issues.apache.org/jira/browse/PROTON-1227
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: go-binding
>    Affects Versions: 0.14.0
>         Environment: RHEL 6.8x
>            Reporter: Jiri Danek
>            Assignee: Alan Conway
>         Attachments: goclientfaf.pcapng, main.go
>
>
> Steps to reproduce: {{go run main.go 127.0.0.1/jms.queue.myqueue}}
> The attached program creates a sender on a at-most-once (a.k.a. 
> fire-and-forget) link. Yet when I Send() a message to qpid-dispatch and have 
> no receiver listening on the same address, the sender timeouts on sending as 
> if it was in at-least-once mode.
> I captured what is happening in the attached packet dump.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to