[
https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Campbell updated CAMEL-1633:
-----------------------------------
Description:
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.
was:
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.
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.
> 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
>
> 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.
