qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway" <acon...@redhat.com>
Subject Re: Review Request: QPID-3280: When sending a large number of messages with nonzero TTLs to a cluster, overall message throughput drops by around 20-30% compared to messages with TTL 0.
Date Thu, 26 May 2011 21:16:54 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/791/#review720
-----------------------------------------------------------


Andrew, can you review out the TimerTask fixes?


/trunk/qpid/cpp/src/qpid/broker/Broker.cpp
<https://reviews.apache.org/r/791/#comment1460>

    Moving the queue cleaner to the cluster timer was done before and reverted:
    
    Author: Gordon Sim <gsim@apache.org>
    Date:   Wed Aug 11 06:06:24 2010
    
        Revert commits r981517 and r981435 that moved periodic purging of
        queues onto cluster's timer. If the timer fires during an update
        it causes errors; it also puts a potentially time consuming task
        on the clusters dispatch thread. Instead don't purge LVQs to avoid
        cluster inconsistencies (and more directly the assertion that aims
        to prevent these).
    
        git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@984357 13f79535-47bb-0310-9956-ffa450edef68
    
    
    However it seems that the cleaner does need to run under the cluster timer as the queue
cleaner could cause policy limit inconsistencies. 
    
    Need to review the reason for reverting this and figure out the proper fix. This could
be done in a separate commit or as part of this one.



/trunk/qpid/cpp/src/qpid/sys/Timer.h
<https://reviews.apache.org/r/791/#comment1461>

    From mail trail: "We modified TimerTask slightly so that it would schedule the next firing
when a cluster task's nextFireTime was in the future (in the even that the elder's deliverWakeup
message was received prior to the local fire time)"
    
    Can you expand a little on why this was needed?


- Alan


On 2011-05-26 20:53:00, Alan Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/791/
> -----------------------------------------------------------
> 
> (Updated 2011-05-26 20:53:00)
> 
> 
> Review request for qpid, Andrew Stitcher, Alan Conway, and Gordon Sim.
> 
> 
> Summary
> -------
> 
> QPID-3280: When sending a large number of messages with nonzero TTLs to a cluster, overall
message throughput drops by around 20-30% compared to messages with TTL 0.
> 
> Replaced the complicated message expirly logic in the cluster with a simpler "cluster
clock" for expiry of messages with TTL.
> 
> Patch supplied by Andy Goldstein <agoldste@redhat.com>.
> 
> 
> Diffs
> -----
> 
>   /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/broker/ExpiryPolicy.h 1128002 
>   /trunk/qpid/cpp/src/qpid/broker/ExpiryPolicy.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/broker/QueueCleaner.h 1128002 
>   /trunk/qpid/cpp/src/qpid/broker/QueueCleaner.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/Cluster.h 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/Cluster.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/ClusterPlugin.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/ClusterSettings.h 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/Connection.h 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/Connection.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/ExpiryPolicy.h 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/ExpiryPolicy.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/cluster/UpdateClient.cpp 1128002 
>   /trunk/qpid/cpp/src/qpid/sys/Timer.h 1128002 
>   /trunk/qpid/cpp/src/qpid/sys/Timer.cpp 1128002 
>   /trunk/qpid/cpp/xml/cluster.xml 1128002 
>   /trunk/qpid/python/examples/api/spout 1128002 
> 
> Diff: https://reviews.apache.org/r/791/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alan
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message