Hi
We have improved the JMX in Camel from Camel 2.7 onwards.
>From the release notes:
Relaxed how aggressive Camel was registering services as MBeans in
JMX. Now Camel will by default only registeres MBeans when starting
CamelContext or starting new routes. This avoids registering too many
MBean
Ah
Found a better solution.
The fileName on the ftp uri supports the simple expression. So what
you can do is
>From a processor / bean where you compute the uri's for the recipient
list you add those headers to pair the url
setHeader("name1", "a.txt")
setHeader("name2", "b.txt")
setHeader("name3
On Tue, Feb 8, 2011 at 3:34 PM, Marco Crivellaro
wrote:
>
> my list of recipients might contain several endpoints which does not
> necessarily make use of the same fileName for the current message so adding
> a processor/bean before the recipientList won't work (file name header
> should be unique
my list of recipients might contain several endpoints which does not
necessarily make use of the same fileName for the current message so adding
a processor/bean before the recipientList won't work (file name header
should be unique for each endpoint).
would it be feasibel to add an interceptSend
On Tue, Feb 8, 2011 at 10:55 AM, Marco Crivellaro
wrote:
>
> Thank you for your reply,
>
>
> I can see a lot of org.apache.camel endpoints, I guess these are related to
> the fact we are sending a huge number of file having a unique file name and
> having the fileName option in the URI is making u
Thank you for your reply,
I can see a lot of org.apache.camel endpoints, I guess these are related to
the fact we are sending a huge number of file having a unique file name and
having the fileName option in the URI is making unique all those endpoints
even though FTP server is always the same (
On Mon, Feb 7, 2011 at 5:38 PM, Marco Crivellaro
wrote:
>
> Yes I am viewing JMX, sorry.
>
>
> but mail recipients or ftp parameters in URI won't allow us to make use of
> the recipientList which is very handy and it is on the basis of our
> application (we are serving a very high number of endpoi
Is disabling JMX an option for you?
This could be a workaround/solution for you.
Christian
Yes I am viewing JMX, sorry.
but mail recipients or ftp parameters in URI won't allow us to make use of
the recipientList which is very handy and it is on the basis of our
application (we are serving a very high number of endpoints dynamically
using the recipientList).
--
View this message in c
On Mon, Feb 7, 2011 at 3:38 PM, Marco Crivellaro
wrote:
>
> I've just used jConsole to analyze our application after running it through
> the weekend, many endpoints URI have been served and all of them have been
> cached. It appears it is not caching 1000 endpoints at most.
Using jconsole you ar
I've just used jConsole to analyze our application after running it through
the weekend, many endpoints URI have been served and all of them have been
cached. It appears it is not caching 1000 endpoints at most.
--
View this message in context:
http://camel.465427.n5.nabble.com/Memory-leak-in-ca
Our system is built on top of the recipientList component and camel
components URI parameters, we are using FTP, JMS, email and HTTP
therefore we'd need a way to 'cleanup' the list of allocated endpoints,
can't you provide a way of forcing endpoints list cleanup or perhaps
customizing the maximum
On Fri, Feb 4, 2011 at 4:00 PM, Marco Crivellaro
wrote:
>
> Hi All,
> I am working together with Sri in a project which makes an extensive use of
> camel (you've seen some posts from me in the past).
> I can confirm the number of endpoints being created grows constantly using
> any protocol,
> wit
Hi All,
I am working together with Sri in a project which makes an extensive use of
camel (you've seen some posts from me in the past).
I can confirm the number of endpoints being created grows constantly using
any protocol,
with our system we are serving a very high number of endpoints and at the
On Wed, Feb 2, 2011 at 11:52 PM, Christian Müller
wrote:
> Claus is right.
> I made a little test which shows that the number of endpoints grows until we
> reach 1000 cached endpoints...
>
The endpoints may still be created in JMX and thus "eat up" memory.
You can try running the test with JMX en
Claus is right.
I made a little test which shows that the number of endpoints grows until we
reach 1000 cached endpoints...
{code}
import javax.mail.internet.AddressException;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;
import org.jvnet.mock_javamail.Mailbox;
pub
I think Sri means the recipient headers we have in camel-mail [1], right?
[1]
https://svn.apache.org/repos/asf/camel/trunk/components/camel-mail/src/main/java/org/apache/camel/component/mail/MailBinding.java
Christian
So when you use the recipient list EIP is that because you use
different mail endpoints every time?
eg you dont have many duplicate endpoint uris?
If uri is unique then Camel have to create a new endpoint every time
and thus it will eat up memory.
On Mon, Jan 31, 2011 at 5:47 PM, Sri wrote:
>
Hello Sri!
I will have a look later this day. If it's a bug, I will rais a JIRA for it.
Cheers,
Christian
Hello,
I have found the problem is with the RecipientList.The MailEndpoint
instances are growing when I use this.
it is working fine and no leak when I use with out recipient list .
I have attached the sample test case file that used for. By the way I am
usng smtp server for my mail test.
R
Hello Sri!
Today, we released Camel 2.6. Could you check, if your issue still exists in
this version?
A code snippet, how you use the mail component, would also be helpful.
Reards,
Christian
21 matches
Mail list logo
