Re: Camel 2.0 -M1 Mail - Sending HTML Email
On Wed, Mar 18, 2009 at 6:23 PM, dougly wrote: > > Hi, > I am using camel 2.0 M1 release. Does the mail component allow HTML email to > be sent? Yeah it should. See the unit test MailHtmlAttachmentTest. You need to set the contentType option to text/html. http://camel.apache.org/mail.html > > Thanks > -- > View this message in context: > http://www.nabble.com/Camel-2.0--M1-Mail---Sending-HTML-Email-tp22584188p22584188.html > Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel JMS Component (ActiveMQ) Repeatedly Reconnects
On Wed, Mar 18, 2009 at 8:07 PM, greenbean wrote:
>
> I made the change you suggested. However, I am getting the same error. :-(
>
> Do you have any other suggestions?
Isnt it because you have CACHE_NONE?
I would assume all resources is cleared after use and thus the it
needs to reconnect on every new message.
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> You should use the ActiveMQ component instead of the generic
>> JmsComponent. Its optimized for AMQ.
>> http://camel.apache.org/activemq.html
>>
>>
>>
>> On Mon, Mar 16, 2009 at 9:37 PM, greenbean wrote:
>>>
>>> Apache Camel 2.0 Snapshot
>>> Apache ActiveMQ 5.2
>>>
>>> When I started Apache Camel I see repeated connect/disconnect events in
>>> activemq. Is there something I have done incorrectly to have activemq do
>>> this? I use ActiveMQ other places (outside of camel) and everything
>>> works
>>> fine.
>>>
>>> Below is the XML configuration and the DEBUG log information from
>>> ActiveMQ.
>>> -
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >> class="com.ngc.ident1.example.camel.CamelProcessor">
>>>
>>> >> class="org.apache.camel.component.jms.JmsComponent">
>>>
>>> >> class="org.apache.activemq.ActiveMQXAConnectionFactory">
>>>
>>> ${local.broker.url}
>>>
>>>
>>>
>>>
>>>
>>> >> ref="transactionManager"
>>> />
>>>
>>> >> class="org.apache.camel.spring.spi.SpringTransactionPolicy">
>>>
>>> >> class="org.springframework.transaction.support.TransactionTemplate">
>>> >> ref="transactionManager" />
>>>
>>>
>>>
>>> -
>>>
>>> 2009-03-16 20:34:08,482 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Task)
>>> Sending: WireFormatInfo { version=3, properties={CacheSize=1024,
>>> CacheEnabled=true, SizePrefixDisabled=false,
>>> MaxInactivityDurationInitalDelay=1, TcpNoDelayEnabled=true,
>>> MaxInactivityDuration=3, TightEncodingEnabled=true,
>>> StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
>>> 2009-03-16 20:34:08,485 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport
>>> Initiator: /127.0.0.1:59998) Sending: WireFormatInfo { version=3,
>>> properties={CacheSize=1024, CacheEnabled=true, SizePrefixDisabled=false,
>>> MaxInactivityDurationInitalDelay=1, TcpNoDelayEnabled=true,
>>> MaxInactivityDuration=3, TightEncodingEnabled=true,
>>> StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
>>> 2009-03-16 20:34:08,485 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport:
>>> tcp:///127.0.0.1:59998) Received WireFormat: WireFormatInfo { version=3,
>>> properties={CacheSize=1024, CacheEnabled=true, SizePrefixDisabled=false,
>>> MaxInactivityDurationInitalDelay=1, TcpNoDelayEnabled=true,
>>> MaxInactivityDuration=3, TightEncodingEnabled=true,
>>> StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
>>> 2009-03-16 20:34:08,485 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport:
>>> tcp:///127.0.0.1:59998) tcp:///127.0.0.1:59998 before negotiation:
>>> OpenWireFormat{version=3, cacheEnabled=false, stackTraceEnabled=false,
>>> tightEncodingEnabled=false, sizePrefixDisabled=false}
>>> 2009-03-16 20:34:08,485 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport:
>>> tcp:///127.0.0.1:59998) tcp:///127.0.0.1:59998 after negotiation:
>>> OpenWireFormat{version=3, cacheEnabled=true, stackTraceEnabled=true,
>>> tightEncodingEnabled=true, sizePrefixDisabled=false}
>>> 2009-03-16 20:34:08,486 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport:
>>> tcp://localhost/127.0.0.1:61616) Received WireFormat: WireFormatInfo {
>>> version=3, properties={CacheSize=1024, CacheEnabled=true,
>>> SizePrefixDisabled=false, MaxInactivityDurationInitalDelay=1,
>>> TcpNoDelayEnabled=true, MaxInactivityDuration=3,
>>> TightEncodingEnabled=true, StackTraceEnabled=true},
>>> magic=[A,c,t,i,v,e,M,Q]}
>>> 2009-03-16 20:34:08,486 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Transport:
>>> tcp://localhost/127.0.0.1:61616) tcp://localhost/127.0.0.1:61616 before
>>> negotiation: OpenWireFormat{version=3, cacheEnabled=false,
>>> stackTraceEnabled=false, tightEncodingEnabled=false,
>>> sizePrefixDisabled=false}
>>> 2009-03-16 20:34:08,486 DEBUG
>>> [org.apache.activemq.transport.WireFormatNegotiator] (ActiveMQ Trans
Re: process() not called when mime type in Base64
Hi Can you see the MailHtmlAttachmentTest unit test for inspiration. It does a send and receive a HTML mail with attachment. On Mon, Mar 16, 2009 at 5:16 PM, Claus Ibsen wrote: > On Mon, Mar 16, 2009 at 4:38 PM, AHardy wrote: >> >> >> Correction, the process() component is called! The Base64 convertor being >> selected does not popluate Exchange.getIn.getAttachments. Is this correct? > That could be. Can you try debugging the code and look for yourself what > happens > > >> -- >> View this message in context: >> http://www.nabble.com/process%28%29-not-called-when-mime-type-in-Base64-tp22539655p22540805.html >> Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Apache Camel RefCard - Review
Hi We are working on a new reference card about Enterprise Integration Patterns with Apache Camel. The card is to be published at DZone at http://refcardz.dzone.com/ The first card, in a two card series, is provided as a final draft and we would like to give the Apache community the opportunity to review and provide feedback. We would love your feedback before we let the designers loose so they can create those beautiful cards that DZone is well know for. I will quote Mr Wei Ling Chen from DZone + QUOTE START Im in the middle of reaching out to reviewers for the Apache Camel Refcard. Could you forward this draft information below to the Camel folks over there please? Please see the PDF draft here: http://mailer.dzone.com/link.php?M=505982&N=206&L=1184&F=H Please submit your comments here: http://mailer.dzone.com/link.php?M=505982&N=206&L=293&F=H I really appreciate your time. As a token of appreciation, every commenter will be entered to a monthly drawing of their choice of free tech books, gifts and refcardz. Submit your comments now for your chance to win (winners selected monthly). See our refcardz collection here: http://refcardz.dzone.com/ and you're interested in writing a refcard, please click here: http://mailer.dzone.com/link.php?M=505982&N=206&L=1185&F=H and we'll contact you to discuss the opportunity. Thanks, Wei ling + QUOTE END -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel JMS Component (ActiveMQ) Repeatedly Reconnects
2009/3/19 Claus Ibsen : > On Wed, Mar 18, 2009 at 8:07 PM, greenbean wrote: >> >> I made the change you suggested. However, I am getting the same error. :-( >> >> Do you have any other suggestions? > Isnt it because you have CACHE_NONE? > > > I would assume all resources is cleared after use and thus the it > needs to reconnect on every new message. Agreed - CACHE_NONE basically means to create a new connection, session, consumer/producer for each message you send/receive then close them all down again. The way to avoid that is to reuse the ActiveMQComponent (as it uses a pooling ConnectionFactory under the hood) or use an explicit pooling connection factory. More details here... http://activemq.apache.org/jmstemplate-gotchas.html -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
Re: Starting, stopping and removing routes at runtime
I'm sorry I'm getting this thread in the middle without reading previous messages, but just one thought: isn't this what ESBs are supposed to manage? I mean, with ESBs we can plug'n play routes easily, add, remove, whatever. If Camel start to have functions like this, wouldn't be overlapping with ESBs functions? How would Camel compare with ServiceMix for example? Please don't shoot. :-) Best regards, Bruno Borges blog.brunoborges.com.br +55 21 76727099 "The glory of great men should always be measured by the means they have used to acquire it." - Francois de La Rochefoucauld On Wed, Mar 18, 2009 at 10:15 AM, m.s. wrote: > > > > >> - can I get a single RouteDefinition, or only a list that I must iterate > >> to > >> find the one I am looking for? > > The API is what we got. But we are open for API changes in Camel 2.0 > > so if you have suggestions what > > you would like changed/added that feedback is much appreciated. > > > > I think a pre check if a route with a certain ID already exists would be > helpful. I would also like to do more things based on the routeID, instead > of getting the list with the RouteDefinitions and then searching for the > one > I want to manipulate. I am thinking about methods like > - RouteDefinition getRouteDefinition(String id) > - void startRoute(String id) > - void stopRoute(String id) > - boolean routeExists(String id) > > On the other hand I am not sure if this is really feasible as the route ID > is an optional attribute. And as these route manipulations at runtime do > not > occur that often, the current API and some additional code in the > application is probably sufficient in most cases. > > M.S. > -- > View this message in context: > http://www.nabble.com/Starting%2C-stopping-and-removing-routes-at-runtime-tp22370230p22578949.html > Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. > >
Re: References to objects processed in routes held, eventually run out of memory
Hi,
Thanks for response.
I'm using Camel 1.6.0 and ActiveMQ 5.2.0. I also had the same results with
camel 1.5 and activeMQ 5.1
I have attached a graph from Jconsole showing what happens as the
application starts, runs for a about 1.5 hours then crashes with out of
memory. http://www.nabble.com/file/p22600122/jconsole-graphs.jpg
Notes:
- I set the maximum memory to 64MB using -Xmx64M -server. normally I would
use more but then the problem takes longer to reproduce
- Notice the number of loaded classes never reduces. I also have another
application which shows the same pattern.
- As the application starts to run out of memory, the CPU usage goes
extremely high
Here is my route:
from("jms:queue:mobileExtTriggerInvites")
.errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(0))
// Exception Handling
.onException(JAXBException.class)
.to("jms:queue:unmarshallableRequest").end()
.onException(UnexpectedEventException.class)
.to("jms:queue:unexpectedEvent").end()
// Log Incoming XML
.to("log:incomingEventXmlLogger?level=INFO")
// Attempt to Unmarshall object expected on this queue
.to("bean:eventMarshaller?methodName=unmarshallTriggerInvites")
// Generate Service Events from this External Event
.to("bean:serviceEventGenerator?methodName=procecssTriggerInvites")
// Split generated Events out of List into individual events
.splitter(body())
// Destination queue for further processing
.to("jms:queue:serviceEventQueue");
You can see that I have 2 bean processors, I have also attached the code for
those.
http://www.nabble.com/file/p22600122/EventMarhaller.txt EventMarhaller.txt
http://www.nabble.com/file/p22600122/ServiceEventGenerator.txt
ServiceEventGenerator.txt
Perhaps it's useful, perhaps not but I read a blog article which sounded
very similar to the problem I am having, link below. Basically it looks like
Camel or ActiveMQ still has a reference to every single object I create and
send through the routing - this would surely explain why the number of
loaded classes gets bigger and bigger the more the application runs.
http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror/
http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror
using JConsole, I also periodically purged the end queue and this made no
difference.
If it helps, I am able to provide a heapdump to anyone for analysis with
jHat. As mentioned in my 1st post, all instances of classes created during
the application lifecycle continue to live on in memory. It appears that my
objects are referenced by ActiveMQMessage
For example, I will trace 1 of those classes created in code attached:
Class:
class
com.ee.berbe.mobile.servicelogic.flightops.events.service.TriggerMMSInvitations
References to this object:
org.apache.activemq.command.activemqobjectmess...@0xafab8fd8 (174 bytes) :
field object
--> -->
Class:
class org.apache.activemq.command.ActiveMQObjectMessage
References to this object:
java.util.linkedhashmap$en...@0xafab8970 (32 bytes) : field value
java.util.linkedhashmap$en...@0xafab8810 (32 bytes) : field value
So it seems that ActiveMQ is still storing all my objets on a LinkedHashMap
but I've no idea why.
Thanks again for any help
Andrew
willem.jiang wrote:
>
> Hi
> Which version of Camel are you using ?
> Can you show us you routing rules and your processor codes?
>
> They will help us to dig the issue.
>
> Willem
>
>
--
View this message in context:
http://www.nabble.com/References-to-objects-processed-in-routes-held%2C-eventually-run-out-of-memory-tp22580791p22600122.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: References to objects processed in routes held, eventually run out of memory
Hi
Just a very quick reply without digging into it yet. There was/is a
leak in camel-jaxb.
I cant remember if we got it fixed in 1.6.0 or its in 1.6.1. At least
its fixed in 2.0m1.
Could you either:
- try without any JAXB
- try with 1.6.1-SNAPSHOT or 2.0m1/2.0-SNAPSHOT
On Thu, Mar 19, 2009 at 2:24 PM, ee7arh wrote:
>
> Hi,
>
> Thanks for response.
>
> I'm using Camel 1.6.0 and ActiveMQ 5.2.0. I also had the same results with
> camel 1.5 and activeMQ 5.1
>
> I have attached a graph from Jconsole showing what happens as the
> application starts, runs for a about 1.5 hours then crashes with out of
> memory. http://www.nabble.com/file/p22600122/jconsole-graphs.jpg
>
> Notes:
>
> - I set the maximum memory to 64MB using -Xmx64M -server. normally I would
> use more but then the problem takes longer to reproduce
> - Notice the number of loaded classes never reduces. I also have another
> application which shows the same pattern.
> - As the application starts to run out of memory, the CPU usage goes
> extremely high
>
> Here is my route:
>
> from("jms:queue:mobileExtTriggerInvites")
>
> .errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(0))
>
> // Exception Handling
> .onException(JAXBException.class)
> .to("jms:queue:unmarshallableRequest").end()
> .onException(UnexpectedEventException.class)
> .to("jms:queue:unexpectedEvent").end()
>
> // Log Incoming XML
> .to("log:incomingEventXmlLogger?level=INFO")
>
> // Attempt to Unmarshall object expected on this queue
> .to("bean:eventMarshaller?methodName=unmarshallTriggerInvites")
>
> // Generate Service Events from this External Event
>
> .to("bean:serviceEventGenerator?methodName=procecssTriggerInvites")
>
> // Split generated Events out of List into individual events
> .splitter(body())
>
> // Destination queue for further processing
> .to("jms:queue:serviceEventQueue");
>
> You can see that I have 2 bean processors, I have also attached the code for
> those.
>
> http://www.nabble.com/file/p22600122/EventMarhaller.txt EventMarhaller.txt
> http://www.nabble.com/file/p22600122/ServiceEventGenerator.txt
> ServiceEventGenerator.txt
>
> Perhaps it's useful, perhaps not but I read a blog article which sounded
> very similar to the problem I am having, link below. Basically it looks like
> Camel or ActiveMQ still has a reference to every single object I create and
> send through the routing - this would surely explain why the number of
> loaded classes gets bigger and bigger the more the application runs.
>
> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror/
> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror
>
> using JConsole, I also periodically purged the end queue and this made no
> difference.
>
> If it helps, I am able to provide a heapdump to anyone for analysis with
> jHat. As mentioned in my 1st post, all instances of classes created during
> the application lifecycle continue to live on in memory. It appears that my
> objects are referenced by ActiveMQMessage
>
> For example, I will trace 1 of those classes created in code attached:
>
> Class:
> class
> com.ee.berbe.mobile.servicelogic.flightops.events.service.TriggerMMSInvitations
>
> References to this object:
> org.apache.activemq.command.activemqobjectmess...@0xafab8fd8 (174 bytes) :
> field object
>
> --> -->
>
> Class:
> class org.apache.activemq.command.ActiveMQObjectMessage
>
> References to this object:
> java.util.linkedhashmap$en...@0xafab8970 (32 bytes) : field value
> java.util.linkedhashmap$en...@0xafab8810 (32 bytes) : field value
>
>
> So it seems that ActiveMQ is still storing all my objets on a LinkedHashMap
> but I've no idea why.
>
> Thanks again for any help
>
> Andrew
>
>
> willem.jiang wrote:
>>
>> Hi
>> Which version of Camel are you using ?
>> Can you show us you routing rules and your processor codes?
>>
>> They will help us to dig the issue.
>>
>> Willem
>>
>>
> --
> View this message in context:
> http://www.nabble.com/References-to-objects-processed-in-routes-held%2C-eventually-run-out-of-memory-tp22580791p22600122.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: References to objects processed in routes held, eventually run out of memory
Hi,
Thanks but we are not using camel-jaxb, everything is being done manually
using the JaxB classes directly (although now I see camel has this built in
I will change well for R2.0 anyway!)
As way of double checking, I found only 7 instances of my unmarshalled
objects in the memory dump, not 1600 like I see for the aforementioned
object in previous post.
Andrew
Claus Ibsen-2 wrote:
>
> Hi
>
> Just a very quick reply without digging into it yet. There was/is a
> leak in camel-jaxb.
> I cant remember if we got it fixed in 1.6.0 or its in 1.6.1. At least
> its fixed in 2.0m1.
>
> Could you either:
> - try without any JAXB
> - try with 1.6.1-SNAPSHOT or 2.0m1/2.0-SNAPSHOT
>
>
>
> On Thu, Mar 19, 2009 at 2:24 PM, ee7arh
> wrote:
>>
>> Hi,
>>
>> Thanks for response.
>>
>> I'm using Camel 1.6.0 and ActiveMQ 5.2.0. I also had the same results
>> with
>> camel 1.5 and activeMQ 5.1
>>
>> I have attached a graph from Jconsole showing what happens as the
>> application starts, runs for a about 1.5 hours then crashes with out of
>> memory. http://www.nabble.com/file/p22600122/jconsole-graphs.jpg
>>
>> Notes:
>>
>> - I set the maximum memory to 64MB using -Xmx64M -server. normally I
>> would
>> use more but then the problem takes longer to reproduce
>> - Notice the number of loaded classes never reduces. I also have another
>> application which shows the same pattern.
>> - As the application starts to run out of memory, the CPU usage goes
>> extremely high
>>
>> Here is my route:
>>
>> from("jms:queue:mobileExtTriggerInvites")
>>
>> .errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(0))
>>
>> // Exception Handling
>> .onException(JAXBException.class)
>> .to("jms:queue:unmarshallableRequest").end()
>> .onException(UnexpectedEventException.class)
>> .to("jms:queue:unexpectedEvent").end()
>>
>> // Log Incoming XML
>> .to("log:incomingEventXmlLogger?level=INFO")
>>
>> // Attempt to Unmarshall object expected on this queue
>>
>> .to("bean:eventMarshaller?methodName=unmarshallTriggerInvites")
>>
>> // Generate Service Events from this External Event
>>
>> .to("bean:serviceEventGenerator?methodName=procecssTriggerInvites")
>>
>> // Split generated Events out of List into individual events
>> .splitter(body())
>>
>> // Destination queue for further processing
>> .to("jms:queue:serviceEventQueue");
>>
>> You can see that I have 2 bean processors, I have also attached the code
>> for
>> those.
>>
>> http://www.nabble.com/file/p22600122/EventMarhaller.txt
>> EventMarhaller.txt
>> http://www.nabble.com/file/p22600122/ServiceEventGenerator.txt
>> ServiceEventGenerator.txt
>>
>> Perhaps it's useful, perhaps not but I read a blog article which sounded
>> very similar to the problem I am having, link below. Basically it looks
>> like
>> Camel or ActiveMQ still has a reference to every single object I create
>> and
>> send through the routing - this would surely explain why the number of
>> loaded classes gets bigger and bigger the more the application runs.
>>
>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror/
>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror
>>
>> using JConsole, I also periodically purged the end queue and this made no
>> difference.
>>
>> If it helps, I am able to provide a heapdump to anyone for analysis with
>> jHat. As mentioned in my 1st post, all instances of classes created
>> during
>> the application lifecycle continue to live on in memory. It appears that
>> my
>> objects are referenced by ActiveMQMessage
>>
>> For example, I will trace 1 of those classes created in code attached:
>>
>> Class:
>> class
>> com.ee.berbe.mobile.servicelogic.flightops.events.service.TriggerMMSInvitations
>>
>> References to this object:
>> org.apache.activemq.command.activemqobjectmess...@0xafab8fd8 (174 bytes)
>> :
>> field object
>>
>> --> -->
>>
>> Class:
>> class org.apache.activemq.command.ActiveMQObjectMessage
>>
>> References to this object:
>> java.util.linkedhashmap$en...@0xafab8970 (32 bytes) : field value
>> java.util.linkedhashmap$en...@0xafab8810 (32 bytes) : field value
>>
>>
>> So it seems that ActiveMQ is still storing all my objets on a
>> LinkedHashMap
>> but I've no idea why.
>>
>> Thanks again for any help
>>
>> Andrew
>>
>>
>> willem.jiang wrote:
>>>
>>> Hi
>>> Which version of Camel are you using ?
>>> Can you show us you routing rules and your processor codes?
>>>
>>> They will help us to dig the issue.
>>>
>>> Willem
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/References-to-objects-processed-in-routes-held%2C-eventually-run-out-of-memory-tp22580791p22600122.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclau
Re: References to objects processed in routes held, eventually run out of memory
Hi again,
A bit more information which might help. I have been running the application
for the last 4 hours with 256MB memory and so far it looks like the
outOfMemory problem will probably not occur anytime soon because the heap
usage drops dramatically after the initial high load processing.
In addition, I have been running messages through further routes to perform
more processing. In my last example, i ran the applciation only through a
simple route but using less memory
Here is the graph:
http://www.nabble.com/file/p22601000/jconsole-graphs-2.jpg
When the application was first started it was under high load so you can see
it took almsot 200MB but after the first 30 mns, fewer messages were
processed and so the application looks to gradually recover the memory.
however, having said all that, notice once again the classes loaded into
memory, it does not follow the same pattern. Number of loaded classes keeps
on increasing so I guess although it may now take a long time, the
application will eventually run out of memory.
Perhaps then there are 2 reasons which can cause an out of memory:
1) When I simply do not have enough memory to facilitate high-load procesing
2) When the nunber of classes in memory continues to increase until no more
memory is left...
Andrew
ee7arh wrote:
>
> Hi,
>
> Thanks but we are not using camel-jaxb, everything is being done manually
> using the JaxB classes directly (although now I see camel has this built
> in I will change well for R2.0 anyway!)
>
> As way of double checking, I found only 7 instances of my unmarshalled
> objects in the memory dump, not 1600 like I see for the aforementioned
> object in previous post.
>
> Andrew
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> Just a very quick reply without digging into it yet. There was/is a
>> leak in camel-jaxb.
>> I cant remember if we got it fixed in 1.6.0 or its in 1.6.1. At least
>> its fixed in 2.0m1.
>>
>> Could you either:
>> - try without any JAXB
>> - try with 1.6.1-SNAPSHOT or 2.0m1/2.0-SNAPSHOT
>>
>>
>>
>> On Thu, Mar 19, 2009 at 2:24 PM, ee7arh
>> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for response.
>>>
>>> I'm using Camel 1.6.0 and ActiveMQ 5.2.0. I also had the same results
>>> with
>>> camel 1.5 and activeMQ 5.1
>>>
>>> I have attached a graph from Jconsole showing what happens as the
>>> application starts, runs for a about 1.5 hours then crashes with out of
>>> memory. http://www.nabble.com/file/p22600122/jconsole-graphs.jpg
>>>
>>> Notes:
>>>
>>> - I set the maximum memory to 64MB using -Xmx64M -server. normally I
>>> would
>>> use more but then the problem takes longer to reproduce
>>> - Notice the number of loaded classes never reduces. I also have another
>>> application which shows the same pattern.
>>> - As the application starts to run out of memory, the CPU usage goes
>>> extremely high
>>>
>>> Here is my route:
>>>
>>> from("jms:queue:mobileExtTriggerInvites")
>>>
>>> .errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(0))
>>>
>>> // Exception Handling
>>> .onException(JAXBException.class)
>>> .to("jms:queue:unmarshallableRequest").end()
>>> .onException(UnexpectedEventException.class)
>>> .to("jms:queue:unexpectedEvent").end()
>>>
>>> // Log Incoming XML
>>> .to("log:incomingEventXmlLogger?level=INFO")
>>>
>>> // Attempt to Unmarshall object expected on this queue
>>>
>>> .to("bean:eventMarshaller?methodName=unmarshallTriggerInvites")
>>>
>>> // Generate Service Events from this External Event
>>>
>>> .to("bean:serviceEventGenerator?methodName=procecssTriggerInvites")
>>>
>>> // Split generated Events out of List into individual events
>>> .splitter(body())
>>>
>>> // Destination queue for further processing
>>> .to("jms:queue:serviceEventQueue");
>>>
>>> You can see that I have 2 bean processors, I have also attached the code
>>> for
>>> those.
>>>
>>> http://www.nabble.com/file/p22600122/EventMarhaller.txt
>>> EventMarhaller.txt
>>> http://www.nabble.com/file/p22600122/ServiceEventGenerator.txt
>>> ServiceEventGenerator.txt
>>>
>>> Perhaps it's useful, perhaps not but I read a blog article which sounded
>>> very similar to the problem I am having, link below. Basically it looks
>>> like
>>> Camel or ActiveMQ still has a reference to every single object I create
>>> and
>>> send through the routing - this would surely explain why the number of
>>> loaded classes gets bigger and bigger the more the application runs.
>>>
>>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror/
>>> http://dertompson.com/2007/08/01/fighting-the-outofmemoryerror
>>>
>>> using JConsole, I also periodically purged the end queue and this made
>>> no
>>> difference.
>>>
>>> If it helps, I am able to provide a heapdump to anyone for analysis with
>>> jHat. As mentioned in my 1st post, all instances of classes created
>>> during
Questions about camel Exchange that contains a CxfMessage with POJO dataFormat
Is the original xml message available given a camel Exchange for a soap message that contains a CxfMessage with POJO dataFormat? Specifically, working in a custom processor, if the inbound message is a CxfMessage with MESSAGE dataFormat, the body is a copy of the original raw message (accessible via exchange.getIn().getBody()). However, if the inbound message is POJO dataFormat, then getBody() only returns a list containing the Java parameters for the operation being invoked. Is there anyway to get at the raw xml message when the inbound message is in POJO dataFormat? Also, is there a way to determine the dataFormat (MESSAGE, PAYLOAD, or POJO) from the camel Exchange or CxfMessage? -Mike
RE: Questions about camel Exchange that contains a CxfMessage with POJO dataFormat
One thing I just noticed... Using getContentFormats() on a POJO CxfMessage for a soap over http endpoint via: CxfMessage message = (CxfMessage) exchange.getIn() message.getMessage().getContentFormats() Returns: [interface java.util.List, class java.io.InputStream, interface javax.xml.stream.XMLStreamReader, interface org.w3c.dom.Node] Will one of these have the original xml message? How do I use these content formats to get that message in w3c format? -Mike From: Michael Ramnarine Sent: Thursday, March 19, 2009 10:46 PM To: 'users@camel.apache.org' Subject: Questions about camel Exchange that contains a CxfMessage with POJO dataFormat Is the original xml message available given a camel Exchange for a soap message that contains a CxfMessage with POJO dataFormat? Specifically, working in a custom processor, if the inbound message is a CxfMessage with MESSAGE dataFormat, the body is a copy of the original raw message (accessible via exchange.getIn().getBody()). However, if the inbound message is POJO dataFormat, then getBody() only returns a list containing the Java parameters for the operation being invoked. Is there anyway to get at the raw xml message when the inbound message is in POJO dataFormat? Also, is there a way to determine the dataFormat (MESSAGE, PAYLOAD, or POJO) from the camel Exchange or CxfMessage? -Mike
