I'm afraid we need a (simple) unit test which shows this issue to
investigate on it.
We also using ActiveMQ in our PROD environment and don't see this issue.
May be it's related to your use of the producer template or an issue in
your custom code...
Can you share your original route (if you are not able to provide a simple
unit test) and your custom beans/processors?

Best,
Christian
-----------------

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Thu, Aug 22, 2013 at 12:13 PM, John D. Ament <john.d.am...@gmail.com>wrote:

> Oh, right now we're in dev mode only.  It's noticeable after a few
> minutes of operating.  The time will fluctuate.  In some cases, I see
> it almost immediately processed and in others I've seen it wait up to
> 10 minutes to process a message (if it takes longer than this we've
> been giving up and trying again).
> Yes, we're using embedded activemq as our broker.
> Most of what we have is operating like a message translator, an in
> bound webservice request gets turned into a POJO and queued (manually,
> via a producer template).  From that point on we simply have bean
> translators (enrichers and filters only) converting the object from
> one type to another until finally it's sent over to the final
> destination in the right format.
> I'm not sure where there would be a memory leak, since we're just
> doing some POJO manipulation and web service invocations.  No, I don't
> have a simple test case that reproduces this yet; though I'll see if
> it happens in other scenarios.
>
> On Thu, Aug 22, 2013 at 5:55 AM, Christian Müller
> <christian.muel...@gmail.com> wrote:
> > Details like:
> > - Which message broker do you use? Which version?
> >   - If you use ActiveMQ, do you use an embedded or external broker?
> > - How does your route look like (Which message exchange pattern do you
> use?
> > Which payload do you use?)
> > - What exactly do you mean with "over the time"? Minutes, hours, days,
> > weeks, ...
> > - How long does it take at the beginning and how long dos it takes after
> x
> > minutes/hours/days/weeks?
> > - Do you have a test case which reproduce the issue?
> > - Did you checked whether there is a memory leak?
> >
> > Best,
> > Christian
> > -----------------
> >
> > Software Integration Specialist
> >
> > Apache Camel committer: https://camel.apache.org/team
> > V.P. Apache Camel: https://www.apache.org/foundation/
> > Apache Member: https://www.apache.org/foundation/members.html
> >
> > https://www.linkedin.com/pub/christian-mueller/11/551/642
> >
> >
> > On Wed, Aug 21, 2013 at 3:18 PM, John D. Ament <john.d.am...@gmail.com
> >wrote:
> >
> >> I guess one other important thing to point out is that this is camel
> >> 2.10.6 on service mix 4.5.3.
> >>
> >> On Wed, Aug 21, 2013 at 9:17 AM, John D. Ament <john.d.am...@gmail.com>
> >> wrote:
> >> > Not sure what more details I could provide.
> >> >
> >> > Basically, I have a polling consumer on a queue.  I see that polling
> >> > consumer polling all the time.  DOesn't see a message, even though the
> >> > message was sent (based on log messages) several minutes back.  Then
> >> > finally after a little bit more the message gets plucked.
> >> >
> >> > On Wed, Aug 21, 2013 at 6:06 AM, Christian Müller
> >> > <christian.muel...@gmail.com> wrote:
> >> >> No, this is not expected. Can you provide more details?
> >> >>
> >> >> Best,
> >> >> Christian
> >> >> Am 21.08.2013 05:55 schrieb "John D. Ament" <john.d.am...@gmail.com
> >:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> Assuming that I'm using activemq queues as my components, how
> quickly
> >> >>> should a message be delivered?
> >> >>>
> >> >>> In a number of routes, I'm moving data from one queue to another
> >> >>> queue, and over time the amount of time that it takes for a message
> to
> >> >>> go from A to B to C is steadily increasing.  Is this expected?
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> John
> >> >>>
> >>
>

Reply via email to