ASF GitHub Bot commented on ARTEMIS-1308:

Github user michaelandrepearce commented on the issue:

    Have added a test case to ensure perf is at least double when many message, 
we expect it to be more as it should no longer block at all and it is, but was 
a good way to test its giving the improvement expected, e.g. the prior to the 
change or reverting the test fails as the perf is equal between the two states.
    Here is a local output of the improvement in consume time of 10,000 when we 
make acknowledge non-blocking.
    [main] 06:13:57,987 INFO  [org.apache.activemq.artemis.jms.tests] 
BlockOnAcknowledge=false MessageCount=10000 TimeToConsume=462980029
    [main] 06:13:57,987 INFO  [org.apache.activemq.artemis.jms.tests] 
BlockOnAcknowledge=true MessageCount=10000 TimeToConsume=38748489101

> Client Acknowledge not performant
> ---------------------------------
>                 Key: ARTEMIS-1308
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Michael Andre Pearce
>            Assignee: clebert suconic
>            Priority: Critical
>             Fix For: 2.3.0
> 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

Reply via email to