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

Michael Andre Pearce edited comment on ARTEMIS-1308 at 7/28/17 4:10 PM:
------------------------------------------------------------------------

The easiest way to recreate the issue of perf is to make a consumer than auto 
acknowledges, and one that does client ack, and ack's each one (with blockonack 
to false to try give it the best chance), then time the difference in consume 
time of say 1000 messages. Then run the same code with other clients, and 
you'll see the issue only being in Artemis Client


was (Author: michael.andre.pearce):
The easiest way to recreate the issue of perf is to make a consumer than auto 
acknowledges, and one that does client ack, and ack's each one (with blockonack 
to false to try give it the best chance), then time the difference in consume 
time of say 1000 messages. Then run the same code with other clients, and 
you'll see the issue.

> Client Acknowledge not performant
> ---------------------------------
>
>                 Key: ARTEMIS-1308
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>            Reporter: Michael Andre Pearce
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to