camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CAMEL-1633) XMPPConsumer.processPacket does not correctly handle received non-message packets.
Date Wed, 10 Jun 2009 04:59:35 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Claus Ibsen resolved CAMEL-1633.
--------------------------------

    Resolution: Fixed

Hi Edward

Thanks for spotting it.

trunk: 783204.
1.x: 783205.

> XMPPConsumer.processPacket does not correctly handle received non-message packets.
> ----------------------------------------------------------------------------------
>
>                 Key: CAMEL-1633
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1633
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-xmpp
>    Affects Versions: 1.6.1
>            Reporter: Edward Campbell
>            Assignee: Claus Ibsen
>             Fix For: 1.6.2, 2.0.0
>
>         Attachments: XmppConsumer.java
>
>
> I am currently porting an application using an in house Smack integration to Apache Camel.
> Specifically, I am getting failures with multiuser chat where messages stop being received
in the middle of the message stream I am sending.
> I have yet to verify the issue exists with private chat as well, but the XMPPConsumer
source looks like there will be a similar issue.
> The XMPPConsumer class registers itself for all packet types in the doStart method, but
in the processPacket method immediately casts the received Packet to Message.
> I have found with the in house integration that Smack sends several types of Packets,
and I could not find assurance that it would not call the packet listener with a null message.
> A simple if((null != packet) && (packet instanceof Message))  should be used
to prevent improper packets from being utilized.
> FYI: the above if statement should also prevent packets from building up in the Smack
message queue, since all messages will be processed without throwing an exception.
> So a call to muc.nextMessage() is unnecessary, and actually detrimental (since if the
next packet is a message, it will be dropped without processing).
> It may be wise to actually use a try/catch block to prevent exceptions from being thrown
by the processPacket method, since messages that throw exceptions seem to stay in the Smack
message queue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message