Hi Orton

Thanks for reporting again.
I have fixed it on trunk and 1.x



On Thu, Mar 26, 2009 at 7:14 PM, orton <[email protected]> wrote:
>
> Hi Claus/XMPP Component Developers,
>
> Soo... the XMPP consumer runs out of memory also, unfortunately. Was doing a
> stand alone consumer test and just found this out. I'm not sure what the
> best way to handle it is, but I did try this and it works:
>
> In the xmpp component, XmppConsumer.java, you have to call muc.nextMessage()
> also (this is surprising, and I'm not sure why it has to be done on the
> consumer side, but it works)
>
> Here's my processPacket()
>
>  public void processPacket(Packet packet) {
>        Message message = (Message)packet;
>
>        if (LOG.isDebugEnabled()) {
>            LOG.debug("Recieved XMPP message: " + message.getBody());
>        }
>
>        XmppExchange exchange = endpoint.createExchange(message);
>        try {
>            getProcessor().process(exchange);
>            muc.nextMessage();  // <------ line added here. not sure if this
> is the best place to call it, but it seems to work here
>        } catch (Exception e) {
>            LOG.error("Error while processing XMPP message", e);
>        }
>    }
>
>
> Is it possible to put this into the 1.6.1 and 2.0 codebase?
>
>
>
>
> Claus Ibsen-2 wrote:
>>
>> On Thu, Mar 19, 2009 at 4:20 PM, orton <[email protected]> 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 <[email protected]>:
>>>>>>
>>>>>> 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/
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Camel-XMPP-1.6-2.0---OutOfMemoryError%3A-Java-heap-space-tp22485629p22727911.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/
Twitter: http://twitter.com/davsclaus

Reply via email to