Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <22601446.post@talk.nabble.com>
Date: Thu, 19 Mar 2009 08:20:18 -0700 (PDT)
From: orton <o_huang@yahoo.com>
To: dev@camel.apache.org
Subject: Re: Camel/XMPP 1.6/2.0 - OutOfMemoryError: Java heap space
In-Reply-To: <22601217.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <22485629.post@talk.nabble.com>
 <ec6e67fd0903130415t410a5b80ib84193351a63099c@mail.gmail.com>
 <22496315.post@talk.nabble.com> <22562234.post@talk.nabble.com>
 <ec6e67fd0903170855x2b198209n65a4834b76b16e3b@mail.gmail.com>
 <22601217.post@talk.nabble.com>


Heard from a co-worker:

When you send a message to the XMPP server (in this case, OpenFire) it sends
a copy back to you and that message has to be dispatched or the queue on the
client side will grow and eventually blow up. So it seems that its necessary
to call muc.nextMessage(). 

I did a quick mod to the Camel 2.0 XMPP component and added the
nextMessage() call to try it out and it does appear to work without throwing
the OOM exception.

In XmppGroupChatProducer:

  public void process(Exchange exchange) {
   ...
        }
        try {
            chat.sendMessage(message);
            chat.nextMessage();
        } catch (XMPPException e) {
            throw new RuntimeXmppException(e);
        }
    }


Same thing prolly has to be done for the XmppPrivateChatProducer

Is this something you can add into the baseline code James?

Thanks!


orton wrote:
> 
> Hi James,
> 
> I haven't had a chance to use JProbe yet, but will attempt that later
> today
> 
> A few things I noticed were:
> 
> The Smack 3.0.4 client has a history of memory issues and there were
> several threads on the Ignite forums regarding the memory issues. I did
> some testing on my own on the Smack client and if I simply do continuous
> muc.sendMessages, then I run into Out of Memory exceptions. Someone
> suggested doing a muc.nextMessage() (which is basically a pull on the muc
> room) after the sendMessage and that actually prevents the OOM error (it
> also reduces the efficiency by quite a bit). I'll try with the Smack 3.1.0
> libraries but I believe the issue still persists in the latest version.
> 
> Though not a permanent fix, it might be useful until Ignite fixes all the
> OOM issues with the Smack clients.
> 
> Here are some references to the OOM errors at Ignite:
> http://www.igniterealtime.org/community/message/189102
> 
> 
> 
> 
> 
> James.Strachan wrote:
>> 
>> Running your app using a profiler (either the one in the JDK or JProbe
>> or something) would provide useful diagnostics as to what's hogging
>> all the RAM - is it the Smack client or something in Camel.
>> 
>> 2009/3/17 orton <o_huang@yahoo.com>:
>>>
>>> Ran some more tests with more memory for the publisher and subscriber,
>>> and it
>>> still runs out of memory. If I give the the sending and receiving JVM
>>> each
>>>
>>> -Xms256M -Xmx512M -Xmn40M
>>>
>>> It runs out of memory at around 54000 4KB messages sent and received.
>>>
>>> Doubling the memory causes it to die around 102000 4KB messages sent and
>>> received
>>>
>>> Any help would be greatly appreciated! Thanks...
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22562234.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>>
>> 
>> 
>> 
>> -- 
>> James
>> -------
>> http://macstrac.blogspot.com/
>> 
>> Open Source Integration
>> http://fusesource.com/
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22601446.html
Sent from the Camel Development mailing list archive at Nabble.com.