On Thu, Mar 19, 2009 at 4:20 PM, orton <o_hu...@yahoo.com> wrote:
>
> 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?
Hi
Excellent. Can you create a ticket in JIRA, then we have a track
record of the changes in Camel
http://camel.apache.org/support.html
>
> 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_hu...@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.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
