[ 
https://issues.apache.org/jira/browse/QPIDJMS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell closed QPIDJMS-507.
----------------------------------
    Resolution: Invalid

It is an async send in the sense that it doesn't need to wait for 
acknowledgement of acceptance from the broker before returning, as it might 
otherwise, not that it does zero work or blocking before returning. There is 
internal blocking as work is done to initiate the actual underlying send (which 
may also including waiting for credit to send if some isnt available). Those 
bits and the timeout for an async send happen within the async work in the 
clients core on the other side of those snippets. The client doesn't wait for 
acknowledgement, but it does actually send (or fail to) before returning.

(If you read the API closely you would see JMS says it allows for part of the 
send work to be async. The API actually allows for anything up to and including 
doing a traditional fully synchronous send where acknowledgement is waited for 
before returning)

> async send isn't really async
> -----------------------------
>
>                 Key: QPIDJMS-507
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-507
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>            Reporter: yair ogen
>            Priority: Critical
>
> When calling send with CompletionListener, the api indicates this create an 
> async call.
> However, it seems that internally, there is still blocking.
> JmsSession has this code:
> {code:java}
> transactionContext.send(connection, envelope, null)
> {code}
> This in turn, calls:
> {code:java}
> connection.send(envelope, new ProviderSynchronization() {
> {code}
> And in there:
> {code:java}
> try {
>     provider.send(envelope, request);
>     request.sync();
> } finally {
>     requests.remove(request);
> }
> {code}
> the sync call is blocking. so it seems there is no real async implementation?
> Also, the sync is called without timeout even if user sets a
> {code:java}
> sendTimeout{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to