[jira] Resolved: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistent store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies resolved AMQ-2103. - Resolution: Fixed Fix Version/s: 5.3.0 Patch applied in SVN revision 743258 > Memory leak when marshaling ActiveMQTextMessage to persistent store > --- > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds >Assignee: Rob Davies > Fix For: 5.3.0 > > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, heap_100_1MB_messages.png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm, > jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistent store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies reassigned AMQ-2103: --- Assignee: Rob Davies > Memory leak when marshaling ActiveMQTextMessage to persistent store > --- > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds >Assignee: Rob Davies > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, heap_100_1MB_messages.png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm, > jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistent store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Summary: Memory leak when marshaling ActiveMQTextMessage to persistent store (was: Memory leak when marshaling ActiveMQTextMessage to persistence store) > Memory leak when marshaling ActiveMQTextMessage to persistent store > --- > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, heap_100_1MB_messages.png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm, > jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: heap_100_1MB_messages.png attaching heap usage graph comparing memory before and after applying patch > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, heap_100_1MB_messages.png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm, > jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQCPP-222) Potential memory leak in OpenWire Commands
[ https://issues.apache.org/activemq/browse/AMQCPP-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-222. - Resolution: Fixed Resolved in the 2.X branch. > Potential memory leak in OpenWire Commands > -- > > Key: AMQCPP-222 > URL: https://issues.apache.org/activemq/browse/AMQCPP-222 > Project: ActiveMQ C++ Client > Issue Type: Improvement > Components: Openwire >Affects Versions: 2.2.1, 2.2.2, 2.2.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 2.2.4 > > > When cloning an Openwire command object its possible for a memory leak to > occur if an exception is thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-222) Potential memory leak in OpenWire Commands
Potential memory leak in OpenWire Commands -- Key: AMQCPP-222 URL: https://issues.apache.org/activemq/browse/AMQCPP-222 Project: ActiveMQ C++ Client Issue Type: Improvement Components: Openwire Affects Versions: 2.2.3, 2.2.2, 2.2.1 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 2.2.4 When cloning an Openwire command object its possible for a memory leak to occur if an exception is thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49312#action_49312 ] Trevor Pounds commented on AMQ-2103: I also forgot to mention that this probably only affects use cases with something like vm transport where the message stays internal to the same JVM and is not marshaled across the wire. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, jhat_ActiveMQTextMessage_0xe837a478.htm, > jhat_ByteSequence_0xe837a5c0.htm, jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: AMQ-2103.diff attaching patch that clears ActiveMQTextMessage 'text' field data when marshaling. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, jhat_ActiveMQTextMessage_0xe837a478.htm, > jhat_ByteSequence_0xe837a5c0.htm, jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: jhat_ByteSequence_data_0xe837adb0.htm attaching jhat heap analysis showing ActiveMQTextMessage->ByteSequence->byte array object holding the message data. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: AMQ-2103.diff, Duplicate Message Data (Internal > Marshalling).png, jhat_ActiveMQTextMessage_0xe837a478.htm, > jhat_ByteSequence_0xe837a5c0.htm, jhat_ByteSequence_data_0xe837adb0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: jhat_ActiveMQTextMessage_0xe837a478.htm attaching jhat heap analysis showing ActiveMQTextMessage object with duplicate data. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: Duplicate Message Data (Internal Marshalling).png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: Duplicate Message Data (Internal Marshalling).png attaching memory usage diagram showing how the message data can be duplicated. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: Duplicate Message Data (Internal Marshalling).png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Attachment: jhat_ByteSequence_0xe837a5c0.htm attaching jhat heap analysis showing ActiveMQTextMessage->ByteSequence object holding the byte array data. > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > Attachments: Duplicate Message Data (Internal Marshalling).png, > jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm > > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Environment: ActiveMQ 5.0.0.20-fuse > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
[ https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Pounds updated AMQ-2103: --- Affects Version/s: (was: 5.2.0) 5.0.0 > Memory leak when marshaling ActiveMQTextMessage to persistence store > > > Key: AMQ-2103 > URL: https://issues.apache.org/activemq/browse/AMQ-2103 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.0.0 > Environment: ActiveMQ 5.0.0.20-fuse >Reporter: Trevor Pounds > > When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the > persistence store some portion of the messages are stored in memory (i.e. > pending cursor/consumer dispatch queue). The messages stored in memory have > the potential to cause the broker to run out of memory because > org.apache.activemq.command.ActiveMQTextMessage objects can store the data > twice, once in the 'text' field and once in the 'content' field. Normally > this isn't a problem since the 'content' field is cleared when the message is > being used in a client application (i.e. by calling getText() clears > content). The problem occurs when a consumer is slow and a large number of > messages are sitting around on the broker in pending/dispatch memory space. > The message is marshaled for the store and then persisted to disk and copied > to pending memory when space is available. > This bug affects any ActiveMQ*Message object that does not clear its > temporary data (i.e. 'text' field) once it has been marshaled. When a > message is marshaled we should null the derived objects memory space once the > data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistence store
Memory leak when marshaling ActiveMQTextMessage to persistence store Key: AMQ-2103 URL: https://issues.apache.org/activemq/browse/AMQ-2103 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Trevor Pounds When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the persistence store some portion of the messages are stored in memory (i.e. pending cursor/consumer dispatch queue). The messages stored in memory have the potential to cause the broker to run out of memory because org.apache.activemq.command.ActiveMQTextMessage objects can store the data twice, once in the 'text' field and once in the 'content' field. Normally this isn't a problem since the 'content' field is cleared when the message is being used in a client application (i.e. by calling getText() clears content). The problem occurs when a consumer is slow and a large number of messages are sitting around on the broker in pending/dispatch memory space. The message is marshaled for the store and then persisted to disk and copied to pending memory when space is available. This bug affects any ActiveMQ*Message object that does not clear its temporary data (i.e. 'text' field) once it has been marshaled. When a message is marshaled we should null the derived objects memory space once the data has been written to the parent object's 'content' field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2096) WARN AdvisoryBroker - Failed to fire message master broker advisory
[
https://issues.apache.org/activemq/browse/AMQ-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49299#action_49299
]
Dan Bucatanschi commented on AMQ-2096:
--
Please see these links for more information I found on this issue:
http://www.nabble.com/-jira--Created%3A-%28AMQ-2096%29-WARN-AdvisoryBroker---Failed-to-fire-message-master-broker-advisory-tp21834409p21936466.html
http://www.nabble.com/-jira--Created%3A-%28AMQ-2096%29-WARN-AdvisoryBroker---Failed-to-fire-message-master-broker-advisory-tp21834409p21936676.html
Thanks,
-Dan
> WARN AdvisoryBroker - Failed to fire message master broker advisory
> ---
>
> Key: AMQ-2096
> URL: https://issues.apache.org/activemq/browse/AMQ-2096
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.2.0
> Environment: mac os x 10.5.6, java 1.5.0_16
>Reporter: freetwix
>
> Starting up activemq with a default configuration + simple authentication +
> mysql-ds like:
>
>
>
> password="${activemq.password}"
> groups="producers,consumers,admins"/>
>
>
>
>
>
>
> read="consumers" admin="admins" />
> read="consumers" admin="admins" />
> write="all" read="all" admin="all" />
> write="all" read="all" admin="all" />
>
>
>
>
>
> and a default mysql-ds as jdbcPersistenceAdapter results in the following
> warning message:
>
> WARN AdvisoryBroker - Failed to fire message master broker advisory
> there seems to be no problems in the further processing of advisory messages,
> but the warning is introduced with the use of the authentication plugin.
> greets,
> jochen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (AMQ-2096) WARN AdvisoryBroker - Failed to fire message master broker advisory
One more thing I would like to add:
It might help actually looking at
https://issues.apache.org/activemq/browse/AMQ-1541 Issue AMQ-1541 . This is
the original request to introduce an Advisory message for whenever the
Broker becomes a Master Broker ("Request for notification on failover in
master/slave configuration"). If one looks at the source file diffs, one can
easily see the where all the code was modified to introduce this kind of
advisory message. Maybe this will help into tracking down the issue more
easily.
Thanks,
-Dan
--
View this message in context:
http://www.nabble.com/-jira--Created%3A-%28AMQ-2096%29-WARN-AdvisoryBroker---Failed-to-fire-message-master-broker-advisory-tp21834409p21936676.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: master.xml > Master/slave out of sync with multiple consumers > > > Key: AMQ-2102 > URL: https://issues.apache.org/activemq/browse/AMQ-2102 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dan James > Attachments: master.xml, MasterSlaveBug.java, slave.xml > > > I'm seeing exceptions like this in a simple master/slave setup: > ERROR Service- Async error occurred: > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > The problem only happens when there are multiple consumers listening to the > queue, and is more likely to occur as there are more consumers listening. > I've written a test program that demonstrates the problem. > I start the master and slave with an empty data directory and let them both > startup and settle. Then start the test program. The test program creates a > specified number of consumers, and then starts queuing 256 messages. The > consumers process the message by sending a reply. The producer counts the > replies. Both consumers and the producer see all the messages, but with > multiple consumers it is very likely that the error above will occur and > several of the messages will still be queued on the slave. > While debugging through the activemq code, I noticed that both the master and > the slave dispatch the message to a consumer's pending list independently. > In other words, it is possible that the master will add the message to > consumer A's pending list and the slave will add the message to consumer B's > pending list. Once the message has been processed by consumer A, the master > sends a message to the slaving which specifies consumer A so that the slave > can remove the message. The slave looks on its copy of consumer A's pending > list and cannot find the message. As a result, it throws this exception and > the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: slave.xml > Master/slave out of sync with multiple consumers > > > Key: AMQ-2102 > URL: https://issues.apache.org/activemq/browse/AMQ-2102 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dan James > Attachments: master.xml, MasterSlaveBug.java, slave.xml > > > I'm seeing exceptions like this in a simple master/slave setup: > ERROR Service- Async error occurred: > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > The problem only happens when there are multiple consumers listening to the > queue, and is more likely to occur as there are more consumers listening. > I've written a test program that demonstrates the problem. > I start the master and slave with an empty data directory and let them both > startup and settle. Then start the test program. The test program creates a > specified number of consumers, and then starts queuing 256 messages. The > consumers process the message by sending a reply. The producer counts the > replies. Both consumers and the producer see all the messages, but with > multiple consumers it is very likely that the error above will occur and > several of the messages will still be queued on the slave. > While debugging through the activemq code, I noticed that both the master and > the slave dispatch the message to a consumer's pending list independently. > In other words, it is possible that the master will add the message to > consumer A's pending list and the slave will add the message to consumer B's > pending list. Once the message has been processed by consumer A, the master > sends a message to the slaving which specifies consumer A so that the slave > can remove the message. The slave looks on its copy of consumer A's pending > list and cannot find the message. As a result, it throws this exception and > the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Description: I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. Master and slave configurations along with MasterSlaveBug.java are attached to this issue. Start master and slave brokers: activemq xbean:master.xml activemq xbean:slave.xml Run with (only one consumer, the bug does not appear): java -classpath .:activemq-all-5.2.0.jar MasterSlaveBug 1 Run with (sixteen consumers, the bug does appear): java -classpath .:activemq-all-5.2.0.jar MasterSlaveBug 16 was: I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. > Master/slave out of sync with multiple consumers > > > Key: AMQ-2102 > URL: https://issues.apache.org/activemq/browse/AMQ-2102 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dan James > Attachments: master.xml, MasterSlaveBug.java, slave.xml > > > I'm seeing exceptions like this in a simple master/slave setup: > ERROR Service- Async error occurred: > javax.jms.JMS
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: MasterSlaveBug.java > Master/slave out of sync with multiple consumers > > > Key: AMQ-2102 > URL: https://issues.apache.org/activemq/browse/AMQ-2102 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dan James > Attachments: MasterSlaveBug.java > > > I'm seeing exceptions like this in a simple master/slave setup: > ERROR Service- Async error occurred: > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > javax.jms.JMSException: Slave broker out of sync with master: Dispatched > message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the > pending list for MasterSlaveBug > The problem only happens when there are multiple consumers listening to the > queue, and is more likely to occur as there are more consumers listening. > I've written a test program that demonstrates the problem. > I start the master and slave with an empty data directory and let them both > startup and settle. Then start the test program. The test program creates a > specified number of consumers, and then starts queuing 256 messages. The > consumers process the message by sending a reply. The producer counts the > replies. Both consumers and the producer see all the messages, but with > multiple consumers it is very likely that the error above will occur and > several of the messages will still be queued on the slave. > While debugging through the activemq code, I noticed that both the master and > the slave dispatch the message to a consumer's pending list independently. > In other words, it is possible that the master will add the message to > consumer A's pending list and the slave will add the message to consumer B's > pending list. Once the message has been processed by consumer A, the master > sends a message to the slaving which specifies consumer A so that the slave > can remove the message. The slave looks on its copy of consumer A's pending > list and cannot find the message. As a result, it throws this exception and > the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2102) Master/slave out of sync with multiple consumers
Master/slave out of sync with multiple consumers Key: AMQ-2102 URL: https://issues.apache.org/activemq/browse/AMQ-2102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Dan James I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-221) "No valid response received for command: %s, check broker.") at ./activemq/transport/CommandIOException.h:67
[ https://issues.apache.org/activemq/browse/AMQCPP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQCPP-221. --- Resolution: Duplicate This is an issue that has arisen in the past, the fixes for this have gone into the later 2.2.x releases, upgrading to the latest 2.2.3 release should resolve the problem. > "No valid response received for command: %s, check broker.") at > ./activemq/transport/CommandIOException.h:67 > > > Key: AMQCPP-221 > URL: https://issues.apache.org/activemq/browse/AMQCPP-221 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 2.1.3 > Environment: Linux orion 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST > 2007 x86_64 x86_64 x86_64 GNU/Linux > #CentOS release 5 (Final) > redhat-4 >Reporter: Wolfgang.Klein >Assignee: Timothy Bish >Priority: Minor > Attachments: core.21565.gz, main.cpp > > > All activemq c++ clients core after missing a response from the broker. It > seems that the broker is in a bad state. > Here i have used the code from > /opt/apache-activemq-5.1.0/activemq-cpp-2.1.3-src/src/examples/main.cpp of > the download software. > #0 0x003dcc476090 in strlen () from /lib64/libc.so.6 > #1 0x003dcc44602b in vfprintf () from /lib64/libc.so.6 > #2 0x003dcc4671fa in vsnprintf () from /lib64/libc.so.6 > #3 0x2ac00c2f in > activemq::exceptions::ActiveMQException::buildMessage (this=Variable "this" > is not available. > ) at activemq/exceptions/ActiveMQException.cpp:76 > #4 0x2ac13708 in CommandIOException (this=0x17c39e60, > file=0x2ad31160 "activemq/transport/filters/ResponseCorrelator.cpp", > lineNumber=146, > msg=0x2ad31198 "No valid response received for command: %s, check > broker.") at ./activemq/transport/CommandIOException.h:67 > #5 0x2ac623c2 in > activemq::transport::filters::ResponseCorrelator::request (this=Variable > "this" is not available. > ) at activemq/transport/filters/ResponseCorrelator.cpp:148 > #6 0x2ac38c1a in > activemq::connector::openwire::OpenWireFormatNegotiator::request > (this=0x17c37660, command=0x17c38d28) > at activemq/connector/openwire/OpenWireFormatNegotiator.cpp:102 > #7 0x2ac3fe2f in > activemq::connector::openwire::OpenWireConnector::syncRequest (this=Variable > "this" is not available. > ) at activemq/connector/openwire/OpenWireConnector.cpp:1349 > #8 0x2ac41511 in > activemq::connector::openwire::OpenWireConnector::send (this=0x17c35cc0, > message=Variable "message" is not available. > ) > at activemq/connector/openwire/OpenWireConnector.cpp:838 > #9 0x2abd994c in activemq::core::ActiveMQSession::send > (this=Variable "this" is not available. > ) at activemq/core/ActiveMQSession.cpp:673 > #10 0x2abe52c0 in activemq::core::ActiveMQProducer::send > (this=0x17c38c70, destination=Variable "destination" is not available. > ) at activemq/core/ActiveMQProducer.cpp:192 > #11 0x2abe4dea in activemq::core::ActiveMQProducer::send (this=0x4, > destination=0x2ad311c0, message=0x43203b98) > at activemq/core/ActiveMQProducer.cpp:147 > #12 0x2abe50fb in activemq::core::ActiveMQProducer::send > (this=0x17c38c70, message=0x17c38d20) at > activemq/core/ActiveMQProducer.cpp:106 > #13 0x004034e0 in HelloWorldProducer::run (this=0x7c892390) at > main.cpp:111 > #14 0x2abff0e0 in activemq::concurrent::Thread::runCallback > (param=Variable "param" is not available. > ) at activemq/concurrent/Thread.cpp:152 > #15 0x003dcd0062e7 in start_thread () from /lib64/libpthread.so.0 > #16 0x003dcc4ce3bd in clone () from /lib64/libc.so.6 > (gdb) info thread > 9 process 21565 0x003dcd0075a5 in pthread_join () from > /lib64/libpthread.so.0 > 8 process 21566 0x003dcd00a687 in pthread_cond_timedwait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 7 process 21569 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 6 process 21571 0x003dcc4cee41 in recv () from /lib64/libc.so.6 > 5 process 21579 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 4 process 21585 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 3 process 21586 0x003dcc4cee41 in recv () from /lib64/libc.so.6 > 2 process 21594 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > * 1 process 21584 0x003dcc476090 in strlen () from /lib64/libc.so.6 > I assume that the command object is created by another thread which dies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the iss
[jira] Updated: (AMQCPP-221) "No valid response received for command: %s, check broker.") at ./activemq/transport/CommandIOException.h:67
[ https://issues.apache.org/activemq/browse/AMQCPP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolfgang.Klein updated AMQCPP-221: -- Attachment: main.cpp core.21565.gz > "No valid response received for command: %s, check broker.") at > ./activemq/transport/CommandIOException.h:67 > > > Key: AMQCPP-221 > URL: https://issues.apache.org/activemq/browse/AMQCPP-221 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 2.1.3 > Environment: Linux orion 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST > 2007 x86_64 x86_64 x86_64 GNU/Linux > #CentOS release 5 (Final) > redhat-4 >Reporter: Wolfgang.Klein >Assignee: Timothy Bish >Priority: Minor > Attachments: core.21565.gz, main.cpp > > > All activemq c++ clients core after missing a response from the broker. It > seems that the broker is in a bad state. > Here i have used the code from > /opt/apache-activemq-5.1.0/activemq-cpp-2.1.3-src/src/examples/main.cpp of > the download software. > #0 0x003dcc476090 in strlen () from /lib64/libc.so.6 > #1 0x003dcc44602b in vfprintf () from /lib64/libc.so.6 > #2 0x003dcc4671fa in vsnprintf () from /lib64/libc.so.6 > #3 0x2ac00c2f in > activemq::exceptions::ActiveMQException::buildMessage (this=Variable "this" > is not available. > ) at activemq/exceptions/ActiveMQException.cpp:76 > #4 0x2ac13708 in CommandIOException (this=0x17c39e60, > file=0x2ad31160 "activemq/transport/filters/ResponseCorrelator.cpp", > lineNumber=146, > msg=0x2ad31198 "No valid response received for command: %s, check > broker.") at ./activemq/transport/CommandIOException.h:67 > #5 0x2ac623c2 in > activemq::transport::filters::ResponseCorrelator::request (this=Variable > "this" is not available. > ) at activemq/transport/filters/ResponseCorrelator.cpp:148 > #6 0x2ac38c1a in > activemq::connector::openwire::OpenWireFormatNegotiator::request > (this=0x17c37660, command=0x17c38d28) > at activemq/connector/openwire/OpenWireFormatNegotiator.cpp:102 > #7 0x2ac3fe2f in > activemq::connector::openwire::OpenWireConnector::syncRequest (this=Variable > "this" is not available. > ) at activemq/connector/openwire/OpenWireConnector.cpp:1349 > #8 0x2ac41511 in > activemq::connector::openwire::OpenWireConnector::send (this=0x17c35cc0, > message=Variable "message" is not available. > ) > at activemq/connector/openwire/OpenWireConnector.cpp:838 > #9 0x2abd994c in activemq::core::ActiveMQSession::send > (this=Variable "this" is not available. > ) at activemq/core/ActiveMQSession.cpp:673 > #10 0x2abe52c0 in activemq::core::ActiveMQProducer::send > (this=0x17c38c70, destination=Variable "destination" is not available. > ) at activemq/core/ActiveMQProducer.cpp:192 > #11 0x2abe4dea in activemq::core::ActiveMQProducer::send (this=0x4, > destination=0x2ad311c0, message=0x43203b98) > at activemq/core/ActiveMQProducer.cpp:147 > #12 0x2abe50fb in activemq::core::ActiveMQProducer::send > (this=0x17c38c70, message=0x17c38d20) at > activemq/core/ActiveMQProducer.cpp:106 > #13 0x004034e0 in HelloWorldProducer::run (this=0x7c892390) at > main.cpp:111 > #14 0x2abff0e0 in activemq::concurrent::Thread::runCallback > (param=Variable "param" is not available. > ) at activemq/concurrent/Thread.cpp:152 > #15 0x003dcd0062e7 in start_thread () from /lib64/libpthread.so.0 > #16 0x003dcc4ce3bd in clone () from /lib64/libc.so.6 > (gdb) info thread > 9 process 21565 0x003dcd0075a5 in pthread_join () from > /lib64/libpthread.so.0 > 8 process 21566 0x003dcd00a687 in pthread_cond_timedwait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 7 process 21569 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 6 process 21571 0x003dcc4cee41 in recv () from /lib64/libc.so.6 > 5 process 21579 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 4 process 21585 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > 3 process 21586 0x003dcc4cee41 in recv () from /lib64/libc.so.6 > 2 process 21594 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > * 1 process 21584 0x003dcc476090 in strlen () from /lib64/libc.so.6 > I assume that the command object is created by another thread which dies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2101) Upgrade dbcp
[ https://issues.apache.org/activemq/browse/AMQ-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-2101. Resolution: Fixed Fixed in SVN revision 742930. > Upgrade dbcp > > > Key: AMQ-2101 > URL: https://issues.apache.org/activemq/browse/AMQ-2101 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.2.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.3.0 > > > Assembly does not respect dbcp version and includes 1.2 (instead of 1.2.2) in > the distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2101) Upgrade dbcp
Upgrade dbcp Key: AMQ-2101 URL: https://issues.apache.org/activemq/browse/AMQ-2101 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.2.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.3.0 Assembly does not respect dbcp version and includes 1.2 (instead of 1.2.2) in the distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-221) "No valid response received for command: %s, check broker.") at ./activemq/transport/CommandIOException.h:67
"No valid response received for command: %s, check broker.") at ./activemq/transport/CommandIOException.h:67 Key: AMQCPP-221 URL: https://issues.apache.org/activemq/browse/AMQCPP-221 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 2.1.3 Environment: Linux orion 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST 2007 x86_64 x86_64 x86_64 GNU/Linux #CentOS release 5 (Final) redhat-4 Reporter: Wolfgang.Klein Assignee: Timothy Bish Priority: Minor All activemq c++ clients core after missing a response from the broker. It seems that the broker is in a bad state. Here i have used the code from /opt/apache-activemq-5.1.0/activemq-cpp-2.1.3-src/src/examples/main.cpp of the download software. #0 0x003dcc476090 in strlen () from /lib64/libc.so.6 #1 0x003dcc44602b in vfprintf () from /lib64/libc.so.6 #2 0x003dcc4671fa in vsnprintf () from /lib64/libc.so.6 #3 0x2ac00c2f in activemq::exceptions::ActiveMQException::buildMessage (this=Variable "this" is not available. ) at activemq/exceptions/ActiveMQException.cpp:76 #4 0x2ac13708 in CommandIOException (this=0x17c39e60, file=0x2ad31160 "activemq/transport/filters/ResponseCorrelator.cpp", lineNumber=146, msg=0x2ad31198 "No valid response received for command: %s, check broker.") at ./activemq/transport/CommandIOException.h:67 #5 0x2ac623c2 in activemq::transport::filters::ResponseCorrelator::request (this=Variable "this" is not available. ) at activemq/transport/filters/ResponseCorrelator.cpp:148 #6 0x2ac38c1a in activemq::connector::openwire::OpenWireFormatNegotiator::request (this=0x17c37660, command=0x17c38d28) at activemq/connector/openwire/OpenWireFormatNegotiator.cpp:102 #7 0x2ac3fe2f in activemq::connector::openwire::OpenWireConnector::syncRequest (this=Variable "this" is not available. ) at activemq/connector/openwire/OpenWireConnector.cpp:1349 #8 0x2ac41511 in activemq::connector::openwire::OpenWireConnector::send (this=0x17c35cc0, message=Variable "message" is not available. ) at activemq/connector/openwire/OpenWireConnector.cpp:838 #9 0x2abd994c in activemq::core::ActiveMQSession::send (this=Variable "this" is not available. ) at activemq/core/ActiveMQSession.cpp:673 #10 0x2abe52c0 in activemq::core::ActiveMQProducer::send (this=0x17c38c70, destination=Variable "destination" is not available. ) at activemq/core/ActiveMQProducer.cpp:192 #11 0x2abe4dea in activemq::core::ActiveMQProducer::send (this=0x4, destination=0x2ad311c0, message=0x43203b98) at activemq/core/ActiveMQProducer.cpp:147 #12 0x2abe50fb in activemq::core::ActiveMQProducer::send (this=0x17c38c70, message=0x17c38d20) at activemq/core/ActiveMQProducer.cpp:106 #13 0x004034e0 in HelloWorldProducer::run (this=0x7c892390) at main.cpp:111 #14 0x2abff0e0 in activemq::concurrent::Thread::runCallback (param=Variable "param" is not available. ) at activemq/concurrent/Thread.cpp:152 #15 0x003dcd0062e7 in start_thread () from /lib64/libpthread.so.0 #16 0x003dcc4ce3bd in clone () from /lib64/libc.so.6 (gdb) info thread 9 process 21565 0x003dcd0075a5 in pthread_join () from /lib64/libpthread.so.0 8 process 21566 0x003dcd00a687 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 process 21569 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 process 21571 0x003dcc4cee41 in recv () from /lib64/libc.so.6 5 process 21579 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 process 21585 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 process 21586 0x003dcc4cee41 in recv () from /lib64/libc.so.6 2 process 21594 0x003dcd00a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 process 21584 0x003dcc476090 in strlen () from /lib64/libc.so.6 I assume that the command object is created by another thread which dies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2100) Concurrent Modification of Delivered Messages in MessageConsumer.dispose()
[ https://issues.apache.org/activemq/browse/AMQ-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies resolved AMQ-2100. - Resolution: Fixed Fixed by SVN revision 742876 > Concurrent Modification of Delivered Messages in MessageConsumer.dispose() > -- > > Key: AMQ-2100 > URL: https://issues.apache.org/activemq/browse/AMQ-2100 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.2.0 >Reporter: Rob Davies >Assignee: Rob Davies > Fix For: 5.3.0 > > > See thread on ActiveMQ user list: > http://www.nabble.com/ConcurrentModificationException-while-closing-consumer-td21867250.html#a21924323 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQNET-135) Error in parsing composite Uri on Linux Mono
[
https://issues.apache.org/activemq/browse/AMQNET-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49267#action_49267
]
Tomasz Wiczling commented on AMQNET-135:
Hi Allan,
the patch, you added, works fine.
Thanks.
> Error in parsing composite Uri on Linux Mono
>
>
> Key: AMQNET-135
> URL: https://issues.apache.org/activemq/browse/AMQNET-135
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
>Affects Versions: 1.1
> Environment: 1. ActiveMQ on linux CentOS 4.4
> 2. Client on Mono 1.9 on linux CentOS 4.4
>Reporter: Tomasz Wiczling
>Assignee: Jim Gomes
>Priority: Critical
> Fix For: 1.1
>
> Attachments: AMQNET-135-741308.diff
>
>
> I'm using ActiveMQ .Net to connect to ActiveMQ from Mono application on linux.
> I've downloaded new (12-12-2008, rev. 726083) version of ActiveMQ .Net and
> started from testing new feature: FAILOVER transport.
> First test made on Windows were very promising, but trying to run my
> application on linux caused an error.
> I've invested it a bit and found out this:
> On linux Mono the System.Uri constructor causes error while parsing composite
> uri, because it replaces all '//' with '/'. And tries to connect to
> 'tcp:/localhost:61616' for example.
> I've tested it on newest Mono 2.0 SUSE with the same result.
> Uris, I've tried:
> failover:(tcp://192.168.44.244:61616)
> failover:(tcp://192.168.44.244:61616)/
> failover://localhost/(tcp://192.168.44.244:61616)
> failover://localhost/(tcp://192.168.44.244:61616)/
> All with the same result :((
> Illustration.
> I modified Apache.NMS.ActiveMQ.ConnectionFactory constructors as below:
> (...)
> public ConnectionFactory(string brokerUri, string clientID)
> : this(new Uri(brokerUri), clientID)
> {
> Tracer.Debug("ConnectionFactory(string brokerUri,
> string clientID): brokerUri='" + brokerUri + "'");
> }
> (...)
> public ConnectionFactory(Uri brokerUri, string clientID)
> {
> Tracer.Debug("ConnectionFactory(Uri brokerUri, string
> clientID): brokerUri='" + brokerUri + "'");
> this.brokerUri = brokerUri;
> this.clientId = clientID;
> }
> (...)
> and prepare simple islustrating program:
> using System;
> using Apache.NMS;
> using Apache.NMS.ActiveMQ;
> namespace IssueExample
> {
> internal class ConsoleTracer : ITrace
> {
> public bool IsDebugEnabled { get { return true; } }
> public bool IsInfoEnabled { get { return true; } }
> public bool IsWarnEnabled { get { return true; } }
> public bool IsErrorEnabled { get { return true; } }
> public bool IsFatalEnabled { get { return true; } }
> public void Debug(string message) { Console.WriteLine("DEBUG:"
> + message); }
> public void Info(string message) { Console.WriteLine("INFO:" +
> message); }
> public void Warn(string message) { Console.WriteLine("WARN:" +
> message); }
> public void Error(string message) { Console.WriteLine("ERROR:"
> + message); }
> public void Fatal(object message) { Console.WriteLine("FATAL:"
> + message); }
> }
> class Program
> {
> public static void Main(string[] args)
> {
> Tracer.Trace = new ConsoleTracer();
> IConnectionFactory factory = new
> ConnectionFactory(args[0]);
> IConnection connection = factory.CreateConnection();
> connection.Close();
> Console.WriteLine("Connected and Disconnected
> successfully to '" + args[0] + "'");
> Console.ReadKey();
> }
> }
> }
> Running my program the output was:
> # mono IssueExample.exe
> failover://localhost/\(tcp://192.168.44.244:61616\,tcp://192.168.44.244:61616\)/
> DEBUG:ConnectionFactory(Uri brokerUri, string clientID):
> brokerUri='failover://localhost/(tcp:/192.168.44.244:61616,tcp:/192.168.44.244:61616)/'
> DEBUG:ConnectionFactory(string brokerUri, string clientID):
> brokerUri='failover://localhost/(tcp://192.168.44.244:61616,tcp://192.168.44.244:61616)/'
> DEBUG:Reconnect was triggered but transport is not started yet. Wait for
> start to connect the transport.
> DEBUG:Started.
> DEBUG:Creating reconnect task
> DEBUG:Waking up reconnect task
> INFO:Waiting for transport to reconnect.
> DEBUG:Attempting connect to: tcp:/192.168.44.244:61616
> DEBUG:Opening socket to: on port: -1
> DEBUG:Connect fail to: tcp:/192.168.44.244:61616, reason:
> System.ArgumentOutOfRangeException:
