You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Edward Campbell (JIRA)" <ji...@apache.org> on 2009/05/20 16:24:50 UTC
[jira] Created: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
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.
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.
[jira] Issue Comment Edited: (CAMEL-1633)
XMPPConsumer.processPacket does not correctly handle received non-message
packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52209#action_52209 ]
Edward Campbell edited comment on CAMEL-1633 at 6/11/09 10:35 AM:
------------------------------------------------------------------
Found out why the order mattered in this case...
According to the smack documentation if you register the same listener multiple times, only the most recent filter is used.
Since the XmppConsumer is being used for all listeners in this case only the last add<Message|Packet>Listener call is honored.
It would be wiser to have the listeners as separate classes, then the handling of each packet/message type can be addressed separately.
A ConnectionListener can be added as well to handle connections that go down and can be retried later.
I'm going to put an improvement request in for this...
was (Author: edward.campbell):
Found out why the order mattered in this case...
According to the smack documentation if you register the same listener multiple times, only the most recent filter is used.
Since the XmppConsumer is being used for all listeners in this case only the last add<Message|Packet>Listener call is honored.
It would be wiser to have the listeners as separate classes, then the handling of each packet/message type can be addressed separately.
A ConnectionListener can be added as well to handle connections that go down and can be retried later.
> 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.
[jira] Updated: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1633:
-------------------------------
Fix Version/s: 2.0.0
1.6.2
> 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
> Fix For: 1.6.2, 2.0.0
>
>
> 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.
[jira] Commented: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52209#action_52209 ]
Edward Campbell commented on CAMEL-1633:
----------------------------------------
Found out why the order mattered in this case...
According to the smack documentation if you register the same listener multiple times, only the most recent filter is used.
Since the XmppConsumer is being used for all listeners in this case only the last add<Message|Packet>Listener call is honored.
It would be wiser to have the listeners as separate classes, then the handling of each packet/message type can be addressed separately.
A ConnectionListener can be added as well to handle connections that go down and can be retried later.
> 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.
[jira] Resolved: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Edward Campbell updated CAMEL-1633:
-----------------------------------
Attachment: XmppConsumer.java
That should fix it.
> 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
> 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.
[jira] Resolved: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-1633.
--------------------------------
Resolution: Fixed
Thanks Edward for reporting and providing the solution.
I have changed the order so the listener is created first.
trunk: 783639.
1.x: 783640.
> 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.
[jira] Reopened: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Edward Campbell reopened CAMEL-1633:
------------------------------------
Only half the patch was applied.
Please apply the changes to the processPacket and processMessage methods from the file I previously attached to fix the problem.
> 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.
[jira] Resolved: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-1633.
--------------------------------
Resolution: Fixed
trunk: 779121.
1.x: 779124.
Applied patch with thanks to Edward Campbell.
> 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.
[jira] Reopened: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Edward Campbell reopened CAMEL-1633:
------------------------------------
My fault.
After going through a bunch of testing, I found some issues with the fix I originally posted.
Specifically the doStart() method of XmppConsumer.java should be as follows:
{code:java}
protected void doStart() throws Exception {
connection = endpoint.createConnection();
if (endpoint.getRoom() == null) {
Chat privateChat = connection.getChatManager().createChat(endpoint.getParticipant(), this);
if (LOG.isInfoEnabled()) {
LOG.info("Open private chat to: " + privateChat.getParticipant());
}
} else {
// add the presence packet listener to the connection so we only get packets that concerns us
final ToContainsFilter toFilter = new ToContainsFilter(endpoint.getParticipant());
final AndFilter packetFilter = new AndFilter(new PacketTypeFilter(Presence.class), toFilter);
connection.addPacketListener(this, packetFilter);
muc = new MultiUserChat(connection, endpoint.resolveRoom(connection));
muc.addMessageListener(this);
DiscussionHistory history = new DiscussionHistory();
history.setMaxChars(0); // we do not want any historical messages
muc.join(endpoint.getNickname(), null, history, SmackConfiguration.getPacketReplyTimeout());
if (LOG.isInfoEnabled()) {
LOG.info("Joined room: " + muc.getRoom() + " as: " + endpoint.getNickname());
}
}
super.doStart();
}
{code}
For some reason the order of adding listeners is important with smack. I haven't yet downloaded the smack source to find out why.
> 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.
[jira] Commented: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51865#action_51865 ]
Claus Ibsen commented on CAMEL-1633:
------------------------------------
Edward feel free to try working on a patch to fix this.
> 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.
[jira] Assigned: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-1633:
----------------------------------
Assignee: Claus Ibsen
> 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.
[jira] Updated: (CAMEL-1633) XMPPConsumer.processPacket does not
correctly handle received non-message packets.
Posted by "Edward Campbell (JIRA)" <ji...@apache.org>.
[ 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.