Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Date: Wed, 27 May 2015 09:17:31 -0700 (PDT)
From: contezero74 <eros.pedrini@gmail.com>
To: users@activemq.apache.org
Message-ID: <1432743451268-4696949.post@n4.nabble.com>
In-Reply-To: 
 <CAPVVMa8QTBminbgpaW2NQSE7zYOauZJEsKsMTdR+FTQwSVpyZg@mail.gmail.com>
References: <1432196087123-4696754.post@n4.nabble.com>
 <CAPVVMa_55Gj=bbE2o5kuDBZ-d3LwDE_qTd-oNeXFFZHf7p9DOQ@mail.gmail.com>
 <1432285592380-4696854.post@n4.nabble.com>
 <CAPVVMa_j2smTjZ9dve0+r--RYETd=8-McxfeNFzTj+z_AS84cA@mail.gmail.com>
 <1432542745202-4696899.post@n4.nabble.com>
 <CAPVVMa8QTBminbgpaW2NQSE7zYOauZJEsKsMTdR+FTQwSVpyZg@mail.gmail.com>
Subject: Re: Performance degrade issue using ActiveMQ scheduler
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tim,
sorry for the late response, but we spent the last days to make the
"workaround" working well.

> My suggestion was that you subdivide your future messages based on time,
> so 
> that only a small number of them are actually scheduled messages (and the 
> rest are normal messages, which the Camel route will schedule later, when 
> the beginning of their holding queue's time window arrives).

To be honest, I misunderstood your suggestion: I understood to create more
scheduled queue and this is way we continue to have the problem. We cannot
follow your approach because the incoming messages are created from an
external application that has its own life-cycle and instructs our
application using the messages themselves.

At the end our "workaround" is very simple:
- we use multiple ActiveMQ support queues and we put in every support queue
the messages that have the same time-window
- every support queue has one polling consumer attached: the consumer
verifies if the processing time is arrived and in case starts to forward the
messages to the queue T

with this solution we are able to match the requirements that we had.
Next steps are
1. create a Camel component in order to be able to reuse the solution in
others projects.
2. return to analyse the ActiveMQ behavior

> ActiveMQ's scheduled messages may not be optimized yet for this volume,
> but 
> I'm not sure they haven't been *designed* for it.  Hopefully with your
> help 
> we can tune them so they can accommodate this load (if indeed that is the 
> problem), and if it turns out the design itself can't accommodate this 
> volume, then hopefully redesigning the algorithm won't be hard. 

probably, you are right: we stressed them to their limit. But for sure the
system has to return to work correctly after the use of the scheduled-area
stops.

P.S. thanks, also for all the hint related to VisualVM

cheers,
Eros


--
View this message in context: http://activemq.2283324.n4.nabble.com/Performance-degrade-issue-using-ActiveMQ-scheduler-tp4696754p4696949.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.