[jira] [Comment Edited] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586886#comment-13586886
 ] 

Tamilmaran edited comment on AMQ-4336 at 2/26/13 7:22 AM:
--

At the time of testing, connectionInterruptedListener and 
connectionResumedListener were like below:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
}
private void connectionResumedListener()
{
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
}
}

Now i changed it like below and started testing again:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
this.firstConnectionAttemptFailed = true;
}

private void connectionResumedListener()
{
Logger.AddBebug("Broker Resumed");
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
Logger.AddBebug("Broker Resumed and restarted");
}
}


  was (Author: tamilmaran):
At the time of testing, connectionInterruptedListener and 
connectionResumedListener were like below:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
}
private void connectionResumedListener()
{
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
}
}
Now i changed it like below and started testing again:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
this.firstConnectionAttemptFailed = true;
}

private void connectionResumedListener()
{
Logger.AddBebug("Broker Resumed");
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
Logger.AddBebug("Broker Resumed and restarted");
}
}

  
> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586886#comment-13586886
 ] 

Tamilmaran edited comment on AMQ-4336 at 2/26/13 7:21 AM:
--

At the time of testing, connectionInterruptedListener and 
connectionResumedListener were like below:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
}
private void connectionResumedListener()
{
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
}
}
Now i changed it like below and started testing again:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
this.firstConnectionAttemptFailed = true;
}

private void connectionResumedListener()
{
Logger.AddBebug("Broker Resumed");
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
Logger.AddBebug("Broker Resumed and restarted");
}
}


  was (Author: tamilmaran):
At the time of testing, connectionInterruptedListener and 
connectionResumedListener are like below:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
}
private void connectionResumedListener()
{
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
}
}
  
> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586886#comment-13586886
 ] 

Tamilmaran commented on AMQ-4336:
-

At the time of testing, connectionInterruptedListener and 
connectionResumedListener are like below:-

private void connectionInterruptedListener()
{
Logger.AddBebug("Broker Interrupted");
}
private void connectionResumedListener()
{
if (this.firstConnectionAttemptFailed)
{
this.OpenBrokerConnection();
this.AddChannels(this.protocolSettings.channelBlocks);
}
}

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586877#comment-13586877
 ] 

Tamilmaran edited comment on AMQ-4336 at 2/26/13 6:57 AM:
--

After setting the producer window size to Max,it seems running yesterday night. 
but when i see it in the morning,consumer is not getting any msg from producer 
i.e.,producer stopped publishing.

Following is the producer log:-
2013-02-25 18:44:41,976: DEBUG – Broker Started
2013-02-25 18:44:41,992: DEBUG – Simulator started.
2013-02-25 18:44:42,429: DEBUG – Hello Request sent for SMS Casino ID: 194
2013-02-25 18:44:42,539: DEBUG – Hello Request sent for SMS Casino ID: 195
2013-02-25 18:44:44,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-25 18:44:45,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-26 06:20:10,070: DEBUG – Broker Interrupted


  was (Author: tamilmaran):
After setting the producer window size to Max,it seems running yesterday 
night. but when i see it in the morning,consumer is not getting any msg from 
producer i.e.,producer stopped publishing.

Following log is from Producer:-
2013-02-25 18:44:41,976: DEBUG – Broker Started
2013-02-25 18:44:41,992: DEBUG – Simulator started.
2013-02-25 18:44:42,429: DEBUG – Hello Request sent for SMS Casino ID: 194
2013-02-25 18:44:42,539: DEBUG – Hello Request sent for SMS Casino ID: 195
2013-02-25 18:44:44,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-25 18:44:45,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-26 06:20:10,070: DEBUG – Broker Interrupted

  
> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586877#comment-13586877
 ] 

Tamilmaran commented on AMQ-4336:
-

After setting the producer window size to Max,it seems running yesterday night. 
but when i see it in the morning,consumer is not getting any msg from producer 
i.e.,producer stopped publishing.

Following log is from Producer:-
2013-02-25 18:44:41,976: DEBUG – Broker Started
2013-02-25 18:44:41,992: DEBUG – Simulator started.
2013-02-25 18:44:42,429: DEBUG – Hello Request sent for SMS Casino ID: 194
2013-02-25 18:44:42,539: DEBUG – Hello Request sent for SMS Casino ID: 195
2013-02-25 18:44:44,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-25 18:44:45,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-26 06:20:10,070: DEBUG – Broker Interrupted


> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Comment: was deleted

(was: After setting the producer window size to Max,it seems running yesterday 
night. but when i see it in the morning,consumer is not getting any msg from 
producer i.e.,producer stops publishing.

Following log is from Producer:-
2013-02-25 18:44:41,976: DEBUG – Broker Started
2013-02-25 18:44:41,992: DEBUG – Simulator started.
2013-02-25 18:44:42,429: DEBUG – Hello Request sent for SMS Casino ID: 194
2013-02-25 18:44:42,539: DEBUG – Hello Request sent for SMS Casino ID: 195
2013-02-25 18:44:44,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-25 18:44:45,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-26 06:20:10,070: DEBUG – Broker Interrupted

)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: SimulatorTC.rar

Modified Bulk Message Producer

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: (was: SimulatorTC.rar)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586874#comment-13586874
 ] 

Tamilmaran commented on AMQ-4336:
-

After setting the producer window size to Max,it seems running yesterday night. 
but when i see it in the morning,consumer is not getting any msg from producer 
i.e.,producer stops publishing.

Following log is from Producer:-
2013-02-25 18:44:41,976: DEBUG – Broker Started
2013-02-25 18:44:41,992: DEBUG – Simulator started.
2013-02-25 18:44:42,429: DEBUG – Hello Request sent for SMS Casino ID: 194
2013-02-25 18:44:42,539: DEBUG – Hello Request sent for SMS Casino ID: 195
2013-02-25 18:44:44,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-25 18:44:45,195: DEBUG – StartUp Done Msg Received. Slot Count: 250
2013-02-26 06:20:10,070: DEBUG – Broker Interrupted



> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Comment: was deleted

(was: Modified Bulk Message Producer)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586869#comment-13586869
 ] 

Tamilmaran edited comment on AMQ-4336 at 2/26/13 6:49 AM:
--

Modified Bulk Message Producer

  was (Author: tamilmaran):
Bulk Message Producer
  
> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: SimulatorTC.rar

Bulk Message Producer

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Comment: was deleted

(was: Bulk Message Producer)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Comment: was deleted

(was: Bulk Message Simulator-ActiveMQ Producer)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: activemq.log

Broker Log

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: (was: SimulatorTC.rar)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.log, activemq.xml
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: SimulatorTC.rar

Bulk Message Producer

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.xml, SimulatorTC.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

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

Tamilmaran updated AMQ-4336:


Attachment: (was: WAPSimulator.rar)

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.xml
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is back to normal : ActiveMQ-Trunk-Deploy #728

[Apache Jenkins Server]

See 

Jenkins build is back to normal : ActiveMQ-Trunk-Deploy » ActiveMQ :: AMQP #728

[Apache Jenkins Server]

See 

[jira] [Commented] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Tamilmaran (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586817#comment-13586817
 ] 

Tamilmaran commented on AMQ-4336:
-

I have set producer window size to Maximum(65535).And i come back to you after 
testing it.

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.xml, WAPSimulator.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Noel Ady (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586449#comment-13586449
 ] 

Noel Ady edited comment on AMQ-3353 at 2/26/13 12:08 AM:
-

Thanks Gary. I can confirm my results are as Andreas Calvo previously stated. 
The situation occurs when you pull the network plug (or do a reboot on the 
hosting operating system). The problem does not occur when you stop and restart 
the activemq broker.Although as Andreas, I have not tried this against 5.8.0. I 
noticed there is a fix in 5.8.0 regarding durable subs, but specifically to 
offline deletions. I intend to run tests against this version before re-opening 
this bug.

  was (Author: noelady):
Thanks Gary. I can confirm my results are as Andreas Calvo previously 
stated. The situation occurs when you pull the network plug (or do a reboot on 
the hosting operating system). The problem does not occur when you stop and 
restart the activemq broker.
  
> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .

[jira] [Commented] (AMQCPP-465) Periodic access violation originating from Openwire::unmarshal

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQCPP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586473#comment-13586473
 ] 

Timothy Bish commented on AMQCPP-465:
-

Pushed new SNAPSHOT that includes the TcpSocket changes.  From my testing this 
seems to be working fine.  Requires some hoop jumping to keep ServerSocket 
working as we get into some tangles because of the APR memory pools and general 
limitations of APR but no issues in the client code should link to that as the 
ServerSocket code doesn't come into play there.  

http://people.apache.org/~tabish/cms-3.6.x/

> Periodic access violation originating from Openwire::unmarshal
> --
>
> Key: AMQCPP-465
> URL: https://issues.apache.org/jira/browse/AMQCPP-465
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Openwire
>Affects Versions: 3.6.0
> Environment: Windows XPSP3 VS2005
>Reporter: Scott Weaver
>Assignee: Timothy Bish
> Attachments: CrashHang_Report__CMStressD.exe__0013114744533.mht, 
> CrashHang_Report__PID_10568__02212013121958303.mht, 
> CrashHang_Report__PID_12904__02212013122442266.mht, 
> CrashHang_Report__PID_13840__02212013122742886.mht, 
> CrashHang_Report__PID_3816__02212013122319960.mht, 
> CrashHang_Report__PID_8784__02212013122829943.mht, TcpSocket.cpp, TcpSocket.h
>
>
> Running a sustained test produced 5 separate access violations all within the 
> Openwire::unmarshal. It appears only one occurred during termination. 
> Attaching all 5 dumps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Noel Ady (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586449#comment-13586449
 ] 

Noel Ady edited comment on AMQ-3353 at 2/25/13 11:25 PM:
-

Thanks Gary. I can confirm my results are as Andreas Calvo previously stated. 
The situation occurs when you pull the network plug (or do a reboot on the 
hosting operating system). The problem does not occur when you stop and restart 
the activemq broker.

  was (Author: noelady):
Thanks Gary. I can confirm my results are as Andreas Calvo previously 
stated.
  
> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .
>  // TestMessageListener's onMessage method simply outputs the message:
> public void onMessage(Message message)
> {
> if ( message instanceof TextMessage )
> {
> System.out.println( "Message received = " + 
> ((TextMessage)message) );
> }
> }
> I can provide the jars for you to run the program if need be.

--
This

[jira] [Commented] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Noel Ady (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586449#comment-13586449
 ] 

Noel Ady commented on AMQ-3353:
---

Thanks Gary. I can confirm my results are as Andreas Calvo previously stated.

> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .
>  // TestMessageListener's onMessage method simply outputs the message:
> public void onMessage(Message message)
> {
> if ( message instanceof TextMessage )
> {
> System.out.println( "Message received = " + 
> ((TextMessage)message) );
> }
> }
> I can provide the jars for you to run the program if need be.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[RESULT][VOTE] Release Apache Apollo 1.6

[Hiram Chirino]

Results of the Apache Apollo 1.6 vote: Vote passes with 8 +1 votes.

Thanks to all who reviewed.  I'll push out the artifacts shortly.

-- 

**

*Hiram Chirino*

*Engineering | Red Hat, Inc.*

*hchir...@redhat.com  | fusesource.com | redhat.com*

*skype: hiramchirino | twitter: @hiramchirino
*

*blog: Hiram Chirino's Bit Mojo *

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Christian Posta (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586387#comment-13586387
 ] 

Christian Posta commented on AMQ-4335:
--

K looks like you're getting the max frame size set properly on the broker. Also 
looks like the client is sending its wire format info which is set to 100MB... 
what version of jars are you using for the client? 

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, 
> AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Andreas Calvo (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586381#comment-13586381
 ] 

Andreas Calvo edited comment on AMQ-3353 at 2/25/13 10:32 PM:
--

[~gtully],
Thanks for the quick reply.
However, although when I made the test it failed (and now it doesn't), I don't 
think it captures truly the situation.
Using a proxy can throw the Inactivity Monitor (even if it's paused or closed), 
but it does not capture an abrupt stop of the broker or it's connections.
While doing more tests in the lab, throwing a socket disconnect error (that 
means, unplugging the network cable) seems to, as [~noelady] expressed, leave 
the durable subscribers in a zombie state: they seem to exists and receive 
packages, but aren't able to dequeue anything.
This fails as of ActiveMQ 5.7, haven't tested yet on 5.8.

If there is any way to cause a socket disconnect error programmatically, it may 
give us a hint.

I may note that, while using ActiveMQ the results are really bad, using 
fuse-09-16 seems to give better results.

Thanks!

  was (Author: acalvo):
[~gtully]
Thanks for the quick reply.
However, although when I made the test it failed (and now it doesn't), I don't 
think it captures truly the situation.
Using a proxy can throw the Inactivity Monitor (even if it's paused or closed), 
but it does not capture an abrupt stop of the broker or it's connections.
While doing more tests in the lab, throwing a socket disconnect error (that 
means, unplugging the network cable) seems to, as [~noelady] expressed, leave 
the durable subscribers in a zombie state: they seem to exists and receive 
packages, but aren't able to dequeue anything.

If there is any way to cause a socket disconnect error programmatically, it may 
give us a hint.

I may note that, while using ActiveMQ the results are really bad, using 
fuse-09-16 seems to give better results.

Thanks!
  
> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> ...

[jira] [Commented] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Andreas Calvo (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586381#comment-13586381
 ] 

Andreas Calvo commented on AMQ-3353:


[~gtully]
Thanks for the quick reply.
However, although when I made the test it failed (and now it doesn't), I don't 
think it captures truly the situation.
Using a proxy can throw the Inactivity Monitor (even if it's paused or closed), 
but it does not capture an abrupt stop of the broker or it's connections.
While doing more tests in the lab, throwing a socket disconnect error (that 
means, unplugging the network cable) seems to, as [~noelady] expressed, leave 
the durable subscribers in a zombie state: they seem to exists and receive 
packages, but aren't able to dequeue anything.

If there is any way to cause a socket disconnect error programmatically, it may 
give us a hint.

I may note that, while using ActiveMQ the results are really bad, using 
fuse-09-16 seems to give better results.

Thanks!

> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .
>  // Tes

[jira] [Commented] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586360#comment-13586360
 ] 

Gary Tully commented on AMQ-3353:
-

peek at the test case that works on trunk: 
https://github.com/apache/activemq/blob/trunk/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/DurableSubscriberWithNetworkDisconnectTest.java

note how it is configured.
To demonstrate a bug, please make some changes to that test case or add some 
additional scenarios and then reopen this issue if it breaks.

> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .
>  // TestMessageListener's onMessage method simply outputs the message:
> public void onMessage(Message message)
> {
> if ( message instanceof TextMessage )
> {
> System.out.println( "Message received = " + 
> ((TextMessage)message) );
> }
> }
> I can provide the jars for you to run the program if need be.

--
This message is automatically generated by JIRA.
If you think it was s

[jira] [Created] (AMQ-4346) Activemq-5.8.0 Shutdown failing when using NIO + LevelDB

[RK G (JIRA)]

RK G created AMQ-4346:
-

 Summary: Activemq-5.8.0 Shutdown failing when using NIO + LevelDB
 Key: AMQ-4346
 URL: https://issues.apache.org/jira/browse/AMQ-4346
 Project: ActiveMQ
  Issue Type: Bug
Reporter: RK G


I configured activemq 5.8.0 with nio connector and leveldb. When ./activemq 
stop is issued shutdown process is throwing an exception. Its a standalone 
installation.

Here is the exception.

2013-02-25 12:15:07,431 | INFO  | Connector amqp Stopped | 
org.apache.activemq.broker.TransportConnector | ActiveMQ ShutdownHook
2013-02-25 12:15:07,549 | INFO  | Stopped LevelDB[/opt/activemq/data/leveldb] | 
org.apache.activemq.leveldb.LevelDBStore | ActiveMQ Sh
utdownHook
2013-02-25 12:15:07,550 | ERROR | Could not stop service: QueueRegion: 
destinations=1, subscriptions=0, memory=0%. Reason: java.lang.N
ullPointerException | org.apache.activemq.broker.jmx.ManagedQueueRegion | 
ActiveMQ ShutdownHook
java.lang.NullPointerException
at 
org.fusesource.hawtdispatch.package$RichExecutor.execute(hawtdispatch.scala:171)
at 
org.fusesource.hawtdispatch.package$RichExecutorTrait$class.apply(hawtdispatch.scala:68)
at 
org.fusesource.hawtdispatch.package$RichExecutor.apply(hawtdispatch.scala:169)
at 
org.fusesource.hawtdispatch.package$RichExecutorTrait$class.future(hawtdispatch.scala:116)
at 
org.fusesource.hawtdispatch.package$RichExecutor.future(hawtdispatch.scala:169)
at 
org.fusesource.hawtdispatch.package$RichExecutorTrait$class.sync(hawtdispatch.scala:107)
at 
org.fusesource.hawtdispatch.package$RichExecutor.sync(hawtdispatch.scala:169)
at 
org.apache.activemq.leveldb.DBManager.destroyPList(DBManager.scala:773)
at 
org.apache.activemq.leveldb.LevelDBStore.removePList(LevelDBStore.scala:454)
at 
org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.destroyDiskList(FilePendingMessageCursor.java:168)
at 
org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.destroy(FilePendingMessageCursor.java:163)
at 
org.apache.activemq.broker.region.cursors.StoreQueueCursor.stop(StoreQueueCursor.java:82)
at org.apache.activemq.broker.region.Queue.stop(Queue.java:910)
at 
org.apache.activemq.broker.region.AbstractRegion.stop(AbstractRegion.java:117)
at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:41)
at 
org.apache.activemq.broker.region.RegionBroker.doStop(RegionBroker.java:574)
at 
org.apache.activemq.broker.jmx.ManagedRegionBroker.doStop(ManagedRegionBroker.java:126)
at 
org.apache.activemq.broker.region.RegionBroker.stop(RegionBroker.java:194)
at org.apache.activemq.broker.BrokerFilter.stop(BrokerFilter.java:161)
at org.apache.activemq.broker.BrokerFilter.stop(BrokerFilter.java:161)
at 
org.apache.activemq.broker.TransactionBroker.stop(TransactionBroker.java:204)
at 
org.apache.activemq.broker.BrokerService$5.stop(BrokerService.java:2070)
at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:41)
at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:715)
at 
org.apache.activemq.xbean.XBeanBrokerService.stop(XBeanBrokerService.java:96)
at 
org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:2282)
at 
org.apache.activemq.broker.BrokerService$6.run(BrokerService.java:2249)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (AMQ-4345) NIOSSLConcurrencyTest.testLoad fails on slow boxes

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-4345.
---

   Resolution: Fixed
Fix Version/s: 5.8.0
 Assignee: Timothy Bish

Fix applied, thanks

> NIOSSLConcurrencyTest.testLoad fails on slow boxes
> --
>
> Key: AMQ-4345
> URL: https://issues.apache.org/jira/browse/AMQ-4345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: Ubuntu, jdk7
>Reporter: Kevin Earls
>Assignee: Timothy Bish
> Fix For: 5.8.0
>
> Attachments: AMQ-4345.patch
>
>
> I'll attach a patch which bumps up the timeout.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4345) NIOSSLConcurrencyTest.testLoad fails on slow boxes

[Kevin Earls (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586292#comment-13586292
 ] 

Kevin Earls commented on AMQ-4345:
--

No, sorry about that.  It should only be a one line change to 
NIOSSLConcurrencyTest.java


> NIOSSLConcurrencyTest.testLoad fails on slow boxes
> --
>
> Key: AMQ-4345
> URL: https://issues.apache.org/jira/browse/AMQ-4345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: Ubuntu, jdk7
>Reporter: Kevin Earls
> Attachments: AMQ-4345.patch
>
>
> I'll attach a patch which bumps up the timeout.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4345) NIOSSLConcurrencyTest.testLoad fails on slow boxes

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586288#comment-13586288
 ] 

Timothy Bish commented on AMQ-4345:
---

Is the pom.xml changes in there relevant to this issue?

> NIOSSLConcurrencyTest.testLoad fails on slow boxes
> --
>
> Key: AMQ-4345
> URL: https://issues.apache.org/jira/browse/AMQ-4345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: Ubuntu, jdk7
>Reporter: Kevin Earls
> Attachments: AMQ-4345.patch
>
>
> I'll attach a patch which bumps up the timeout.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4345) NIOSSLConcurrencyTest.testLoad fails on slow boxes

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-4345:
-

Attachment: AMQ-4345.patch

> NIOSSLConcurrencyTest.testLoad fails on slow boxes
> --
>
> Key: AMQ-4345
> URL: https://issues.apache.org/jira/browse/AMQ-4345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: Ubuntu, jdk7
>Reporter: Kevin Earls
> Attachments: AMQ-4345.patch
>
>
> I'll attach a patch which bumps up the timeout.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Lucille Wilson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586285#comment-13586285
 ] 

Lucille Wilson commented on AMQ-4335:
-

I changed the spelling of "wireFormat" to capitalize the "F".
Then I went back to running AMQ4335Test3_WithLargeGeneratedString.
What I saw in my activemq.log was: 

2013-02-25 15:57:45,818 | DEBUG | localhost adding destination: 
topic://ActiveMQ.Advisory.Producer.Queue.TEST.LARGE.FILE | 
org.apache.activemq.broker.region.AbstractRegion | ActiveMQ Transport: 
tcp:///192.168.2.106:55568@61616
2013-02-25 15:57:46,476 | DEBUG | Transport Connection to: 
tcp://192.168.2.106:55568 failed: java.io.IOException: Frame size of 100 MB 
larger than max allowed 100 MB | 
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: 
tcp:///192.168.2.106:55568@61616
java.io.IOException: Frame size of 100 MB larger than max allowed 100 MB
at 
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:277)
at 
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at 
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at 
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
at java.lang.Thread.run(Thread.java:662)


But what I hadn't noticed before was lines in the activemq.log file which 
looked like this:

2013-02-25 15:57:45,783 | DEBUG | Sending: WireFormatInfo { version=9, 
properties={MaxFrameSize=157286400, CacheSize=1024, CacheEnabled=true, 
SizePrefixDisabled=false, MaxInactivityDurationInitalDelay=1, 
TcpNoDelayEnabled=true, MaxInactivityDuration=3, TightEncodingEnabled=true, 
StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]} | 
org.apache.activemq.transport.WireFormatNegotiator | ActiveMQ 
BrokerService[localhost] Task-2
2013-02-25 15:57:45,784 | DEBUG | Using min of local: WireFormatInfo { 
version=9, properties={MaxFrameSize=157286400, CacheSize=1024, 
CacheEnabled=true, SizePrefixDisabled=false, 
MaxInactivityDurationInitalDelay=1, TcpNoDelayEnabled=true, 
MaxInactivityDuration=3, TightEncodingEnabled=true, 
StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]} and remote: WireFormatInfo { 
version=9, properties={CacheSize=1024, MaxFrameSize=104857600, 
CacheEnabled=true, SizePrefixDisabled=false, TcpNoDelayEnabled=true, 
MaxInactivityDurationInitalDelay=1, MaxInactivityDuration=3, 
TightEncodingEnabled=true, StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]} | 
org.apache.activemq.transport.InactivityMonitor | ActiveMQ Transport: 
tcp:///192.168.2.106:55568@61616
2013-02-25 15:57:45,784 | DEBUG | Received WireFormat: WireFormatInfo { 
version=9, properties={CacheSize=1024, MaxFrameSize=104857600, 
CacheEnabled=true, SizePrefixDisabled=false, TcpNoDelayEnabled=true, 
MaxInactivityDurationInitalDelay=1, MaxInactivityDuration=3, 
TightEncodingEnabled=true, StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]} | 
org.apache.activemq.transport.WireFormatNegotiator | ActiveMQ Transport: 
tcp:///192.168.2.106:55568@61616
2013-02-25 15:57:45,784 | DEBUG | tcp:///192.168.2.106:55568@61616 before 
negotiation: OpenWireFormat{version=9, cacheEnabled=false, 
stackTraceEnabled=false, tightEncodingEnabled=false, sizePrefixDisabled=false, 
maxFrameSize=157286400} | org.apache.activemq.transport.WireFormatNegotiator | 
ActiveMQ Transport: tcp:///192.168.2.106:55568@61616
2013-02-25 15:57:45,784 | DEBUG | tcp:///192.168.2.106:55568@61616 after 
negotiation: OpenWireFormat{version=9, cacheEnabled=true, 
stackTraceEnabled=true, tightEncodingEnabled=true, sizePrefixDisabled=false, 
maxFrameSize=104857600} | org.apache.activemq.transport.WireFormatNegotiator | 
ActiveMQ Transport: tcp:///192.168.2.106:55568@61616

I think it may be that maxFrameSize is overriden in some code, but then set 
back to the default of 100MB in other code.  There is a discrepancy between 
values in maxFrameSize in the lines labeled 'Using min of local', 'Received 
WireFormat', 'before negotiation', and 'after negotiation'.

I still think there is a bug.
Lucille Wilson

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, 
> AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying

[jira] [Created] (AMQ-4345) NIOSSLConcurrencyTest.testLoad fails on slow boxes

[Kevin Earls (JIRA)]

Kevin Earls created AMQ-4345:


 Summary: NIOSSLConcurrencyTest.testLoad fails on slow boxes
 Key: AMQ-4345
 URL: https://issues.apache.org/jira/browse/AMQ-4345
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
 Environment: Ubuntu, jdk7
Reporter: Kevin Earls


I'll attach a patch which bumps up the timeout.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Christian Posta (JIRA)]

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

Christian Posta updated AMQ-4335:
-

Attachment: AMQ4335SmallPayloadTest.java

Updated unit test for small payload... note use "wireFormat.maxFrameSize=***" 
in the config

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, 
> AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Christian Posta (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586179#comment-13586179
 ] 

Christian Posta commented on AMQ-4335:
--

Lucille,

My apologies. I didn't the proper asserts in there. I'll update my test case.

But I also wanted to point out something I noticed that I overlooked originally.
"wireFormat.*" should be spelled with camel humps, not as you have it in your 
config "wireformat"

I will update the test cases. Please do so on your side and let us know.

{code:xml}

{code}


> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-3353) Durable subscribers on durable topics don't receive messages after network disconnect

[Noel Ady (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586149#comment-13586149
 ] 

Noel Ady commented on AMQ-3353:
---

We have been experiencing this same issue on 5.7.0. When AMQ server is rebooted 
all clients reconnect as expected. However durable subscribers show as active 
but the consumer is not pulling new messages. You can see on the subscribers 
page, messages are being en-queued to the durable sub but not being de-queued. 
It has caused some expensive mistakes recently. Havng read through the above , 
I am still unclear on what the best workaround is or if a fix is in progress? 

> Durable subscribers on durable topics don't receive messages after network 
> disconnect
> -
>
> Key: AMQ-3353
> URL: https://issues.apache.org/jira/browse/AMQ-3353
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1, 5.5.0
> Environment: Windows & Linux
> JDK 1.6
>Reporter: Syed Faraz Ali
>Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, 
> DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
> embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
> standalone2.xml, 
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  
> TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
>  test-results.ods
>
>
> I've set up a durable topic with the default (persistent) delivery mode on 
> one machine that is publishing a simple text message every 5 seconds. I 
> created a durable subscriber that consumes messages published to the above 
> topic on another machine. I am using broker to broker communication between 
> the two machines.
> I start up the two programs on either machine and see the messages coming 
> through to the subscriber. If I then pull the network cable to disconnect the 
> network between the two machines, wait for a minute and then plug it back in, 
> my subscriber doesn't receive the messages any more. I can see from the 
> output that the publisher is still publishing them (Temporary topics, 
> non-durable queues all continue to sync up in our production environment, it 
> is only the durable topics that don't work after network reconnect)
> If I were to tweak a setting on the publisher's broker (that was introduced 
> only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
> work correctly after network reconnect. But this may have other unintended 
> consequences and I was hoping to get a better idea of:
> - is this a known issue ? if so, then are there any specific challenges that 
> have caused it not to be fixed?
> - are other people out there using durable topics and subscribers without a 
> failover option that have run into this problem? What have they done to work 
> around?
> Here is how my subscriber and publisher are set up:
> Topic Publisher (Machine 1)
> publisherConnection = connFactory.createConnection();
> publisherConnection.setClientID( "ProducerCliID" );
> publisherConnection.start();
> session = publisherConnection.createSession( true, -1 );
> Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
> producer = session.createProducer( (Topic)producerTopic );
> 
> 
> 
> // On a timer, keep sending this out every 5 seconds
>  String text = "HELLO " + count++;
> TextMessage msg = session.createTextMessage( text );
> System.out.println( "Sending TextMessage = " + msg.getText() 
> );
> producer.send( msg );
> session.commit();
> Subscriber ( Machine 2):
> Connection clientConnection = connFactory.createConnection();
> clientConnection.setClientID("cliID");
> clientConnection.start();
> Session session = clientConnection.createSession( false, 
> Session.AUTO_ACKNOWLEDGE );
> Destination topic = session.createTopic( topicName );
> MessageConsumer subscriber = session.createDurableSubscriber( 
> (Topic)topic, "subName" );
> TestMessageListener msgListener = new TestMessageListener( 1000 );
> subscriber.setMessageListener( msgListener );
> .
> .
>  // TestMessageListener's onMessage method simply outputs the message:
> public void onMessage(Message message)
> {
> if ( message instanceof TextMessage )
> {
> System.out.println( "Message received = " + 
> ((TextMessage)message) );
> }
> }
> I can provide the jars for you t

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Lucille Wilson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586124#comment-13586124
 ] 

Lucille Wilson commented on AMQ-4335:
-

Dear Christian,
I used the AMQ4335SmallPayloadTest.java and the amq4335-small.xml.  I renamed 
the xml to activemq.xml. 
When I ran the AMQ4335SmallPayloadTest.java the Junit test showed green (which 
is what has been happening all along) but the message was not enqueued on the 
TEST.SMALL.MESSAGE queue.  In addition whatever setting there is in the 
amq4335-small.xml which enables the admin/queue.jsp, that setting was not 
enabled.

So my test did not show the "frame size of 2 mb is larger than max allowed 1 mb 
message" I was expecting.

I am running on Windows 7 Professional 64 bit operating system.  

Since I can readily and easily reproduce the problem showing that the max frame 
size is always the default of 100MB what would you like from me in order to 
show you this bug?

In the meantime, if there is any configuration or action we should take to 
override the default of 100mb to a larger number, please advise.

Lucille Wilson

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (AMQ-4319) ActiveMQ destination are tracked by securitycontext and never cleaned up, causes ActiveMQ to crash.

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-4319.
---

   Resolution: Fixed
Fix Version/s: 5.9.0

Fix and test added on trunk.

> ActiveMQ destination are tracked by securitycontext and never cleaned up, 
> causes ActiveMQ to crash.
> ---
>
> Key: AMQ-4319
> URL: https://issues.apache.org/jira/browse/AMQ-4319
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0
> Environment: RHEL 6
>Reporter: Matt Woodson
>Assignee: Timothy Bish
> Fix For: 5.9.0
>
> Attachments: AMQ-4319-unittest.patch
>
>
> We are using ActiveMQ + mcollective.  With mcollective, we are using the 
> "activemq connector 
> ([http://docs.puppetlabs.com/mcollective/reference/plugins/connector_activemq.html])"
> We are running ActiveMQ in the EC2 Cloud, so we have enabled security for the 
> connections being made.
> We have 2 ActiveMQ servers that are configures as network of brokers, about 
> around 200 nodes that we communicate with.
> The problem we are seeing is that after about 1 week in operation, ActiveMQ 
> will crash because it runs out of memory.  We have been monitoring the heap, 
> and you will see it rise during the week, and then the wrapper will 
> eventually restart activemq
> {code:title=wrapper.log}
> ERROR  | wrapper  | 2013/02/01 09:38:33 | JVM appears hung: Timed out waiting 
> for signal from JVM.
> ERROR  | wrapper  | 2013/02/01 09:38:33 | JVM did not exit on request, 
> terminated
> INFO   | wrapper  | 2013/02/01 09:38:33 | JVM exited on its own while waiting 
> to kill the application.
> STATUS | wrapper  | 2013/02/01 09:38:33 | JVM exited in response to signal 
> SIGKILL (9).
> STATUS | wrapper  | 2013/02/01 09:38:38 | Launching a JVM...}
> {code}
> In the activemq connector page, it says that there needs to be cleanup of 
> queues.  This is put into place.
> I did a heap dump, and with external help I was told that "the authentication 
> plugin is retaining destinations in a cached connection"
> These connections need to be deleted and cleaned up as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Christian Posta (JIRA)]

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

Christian Posta updated AMQ-4335:
-

Attachment: amq4335-small.xml
AMQ4335SmallPayloadTest.java

All,

I've tried to reproduce this using the attached test case (which spins up a 
broker using the attached config), using the standalone broker and Lucille's 
test, on windows 7, on Mac, and all combinations thereof. 

I cannot reproduce. 

The only thing else I see different is Windows 2008 R2. But other than that, 
there must be something else external to the brokers or some other config 
that's being missed. Pat, Lucille, If you can take my attached test case (or 
modify Tim's, which I did) and reproduce using that, then we can fix something. 
Otherwise, I'm not seeing any broken behavior.

Cheers

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335SmallPayloadTest.java, amq4335-small.xml, 
> AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (AMQ-4319) ActiveMQ destination are tracked by securitycontext and never cleaned up, causes ActiveMQ to crash.

[Timothy Bish (JIRA)]

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

Timothy Bish reassigned AMQ-4319:
-

Assignee: Timothy Bish

> ActiveMQ destination are tracked by securitycontext and never cleaned up, 
> causes ActiveMQ to crash.
> ---
>
> Key: AMQ-4319
> URL: https://issues.apache.org/jira/browse/AMQ-4319
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0
> Environment: RHEL 6
>Reporter: Matt Woodson
>Assignee: Timothy Bish
> Attachments: AMQ-4319-unittest.patch
>
>
> We are using ActiveMQ + mcollective.  With mcollective, we are using the 
> "activemq connector 
> ([http://docs.puppetlabs.com/mcollective/reference/plugins/connector_activemq.html])"
> We are running ActiveMQ in the EC2 Cloud, so we have enabled security for the 
> connections being made.
> We have 2 ActiveMQ servers that are configures as network of brokers, about 
> around 200 nodes that we communicate with.
> The problem we are seeing is that after about 1 week in operation, ActiveMQ 
> will crash because it runs out of memory.  We have been monitoring the heap, 
> and you will see it rise during the week, and then the wrapper will 
> eventually restart activemq
> {code:title=wrapper.log}
> ERROR  | wrapper  | 2013/02/01 09:38:33 | JVM appears hung: Timed out waiting 
> for signal from JVM.
> ERROR  | wrapper  | 2013/02/01 09:38:33 | JVM did not exit on request, 
> terminated
> INFO   | wrapper  | 2013/02/01 09:38:33 | JVM exited on its own while waiting 
> to kill the application.
> STATUS | wrapper  | 2013/02/01 09:38:33 | JVM exited in response to signal 
> SIGKILL (9).
> STATUS | wrapper  | 2013/02/01 09:38:38 | Launching a JVM...}
> {code}
> In the activemq connector page, it says that there needs to be cleanup of 
> queues.  This is put into place.
> I did a heap dump, and with external help I was told that "the authentication 
> plugin is retaining destinations in a cached connection"
> These connections need to be deleted and cleaned up as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Apache Apollo 1.6

[Christian Posta]

+1.


On Fri, Feb 22, 2013 at 9:06 AM, Gaurav Sharma
wrote:

> +1
>
> Thanks Hiram.
>
> On Feb 20, 2013, at 10:49, Hiram Chirino  wrote:
>
> Hi Everyone,
>
> I've deployed a 1.6 release candidate to pickup fixes and new features
> since the 1.5 release.  It would be nice to release this before Apache Con
> NA.
> This release features improvements like:
>
> * [APLO-275] - Add AMQP 1.0 Protocol Support
> * [APLO-273] - STOMP 1.1 Over WebSocket
> * [APLO-268] - Examples for stompest Python STOMP client
> * [APLO-280] - Clarification about message groups
> * [APLO-19]  - Support message groups
> * [APLO-271] - Integrate jolokia into Apollo for nice REST based access to
> JMX.
> * [APLO-272] - Support creating topics and queues via the REST management
> api.
> * [APLO-274] - Support accessing environment variables via \${env.*}
> references in the the config file.
> * [APLO-278] - Support option on queues to control if a round robin message
> distribution strategy should be used when multiple consumer are attached to
> the queue.
>
> Full Changlog available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311310&version=12322470
>
> The release candidate has been staged to nexus under:
> https://repository.apache.org/content/repositories/orgapacheactivemq-278/
>
> Source code distros can be found at:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apollo-project/1.6/
>
> Binary distros can be found at:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apache-apollo/1.6/
>
> The build was tagged at:
>
> http://svn.apache.org/repos/asf/activemq/activemq-apollo/tags/apollo-project-1.6/
>
> The project website for that version has been staged to:
> http://activemq.apache.org/apollo/versions/1.6/website/index.html
>
> Please vote to approve this release
>
> [ ] +1 Release Apache Apollo 1.6
> [ ] -1 Veto the release (provide specific comments)
>
> As usual, the vote will be open for at least 72 hours.
>
> Here's my +1
>
> --
>
> **
>
> *Hiram Chirino*
>
> *Engineering | Red Hat, Inc.*
>
> *hchir...@redhat.com  | fusesource.com | redhat.com*
>
> *skype: hiramchirino | twitter: @hiramchirino<
> http://twitter.com/hiramchirino>
> *
>
> *blog: Hiram Chirino's Bit Mojo *
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta

[jira] [Commented] (AMQ-4338) MQTTSSLTest has multiple test cases that fail frequently

[Kevin Earls (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585942#comment-13585942
 ] 

Kevin Earls commented on AMQ-4338:
--

Actually, you're right, those are probably not sensible.  The problem test 
cases include:

testSendAndReceiveAtLeastOnce
testSendAtLeastOnceReceiveAtMostOnce
testSendAtLeastOnceReceiveExactlyOnce
testSendJMSReceiveMQTT

On my mac all test cases run in less that 3 seconds.  On Ubuntu and AIX, the 
cases named above sometimes run for ~120 seconds, and sometimes can run even 
longer, or just hang if there's no timeout.



> MQTTSSLTest has multiple test cases that fail frequently
> 
>
> Key: AMQ-4338
> URL: https://issues.apache.org/jira/browse/AMQ-4338
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Priority: Minor
> Attachments: AMQ-4338A.patch, AMQ-4338.patch
>
>
> MQTTSSLTest has multiple different test cases (including 
> testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, 
> testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, 
> testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, 
> testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the 
> provider.connect() call in initializeConnection() as shown in the stacktrace 
> below. 
> Another problem with this test is it was giving a misleading error when run 
> under Hudson, showing that the test that followed it (MQTTTest) was failing 
> instead.  I think this was because of the way it was using 
> AutoFailTestSupport.  I will attach a patch which removes that and uses 
> timeouts on @Test annotations instead.
> testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest)
>   Time elapsed: 30.004 sec  <<< ERROR!
> java.lang.Exception: test timed out after 3 milliseconds
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.fusesource.mqtt.client.Promise.await(Promise.java:88)
> at 
> org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49)
> at 
> org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39)
> at 
> org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60)
> Results :
> Tests in error:
>   
> MQTTSSLTest>AbstractMQTTTest.testSendAndReceiveLargeMessages:247->initializeConnection:60
>  »

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4340) When client uses the latest Java release, (eg. jdk1.7.0_13, jdk 1.7.0_9), client ssl connection fails when broker is set to use nio+ssl, and simpleAuthenticationPlugin

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585926#comment-13585926
 ] 

Timothy Bish commented on AMQ-4340:
---

There were some recent NIO transport fixes which would ripple into the NIO+SLL 
case as well, have you tested using the most recent 5.9-SNAPSHOT?

> When client uses the latest Java release, (eg. jdk1.7.0_13, jdk 1.7.0_9), 
> client ssl connection fails when broker is set to use nio+ssl, and 
> simpleAuthenticationPlugin
> ---
>
> Key: AMQ-4340
> URL: https://issues.apache.org/jira/browse/AMQ-4340
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.6.0, 5.7.0
> Environment: broker is running on Linux 2.6.18-308.1.el5. Client is 
> running in window7 (64bit)
>Reporter: Yelu huang
>
> When client uses jdk1.7.0_13 or 1.7.0_9 and tries to make a ssl connection to 
> a broker which has a transportConnector set as:
>
> and a simple plugin like:
>  
>   
>  
> password="manager" groups="users,admins"/>
> password="rabbit" groups="users"/>
> password="password" groups="guests"/>
> 
>  
>  
> The connection got javax.jms.JMSException: java.io.EOFException. You can 
> reproduce it by simply running an example ProducerTool provided by Activemq.
> It is noted if client uses java 1.6, we have no problem to run the same 
> program. Or if client still uses jdk1.7.0_13, 1.7.0_9, but broker remove nio, 
> ie, just use ssl for transportConnector, we have no problem too. So the 
> problem is nio+ssl is not working properly with the recent Java release. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4338) MQTTSSLTest has multiple test cases that fail frequently

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585924#comment-13585924
 ] 

Timothy Bish commented on AMQ-4338:
---

Are you sure those timeouts are sensible, going from 3 to 30 seems like 
there must be something else going on.  

> MQTTSSLTest has multiple test cases that fail frequently
> 
>
> Key: AMQ-4338
> URL: https://issues.apache.org/jira/browse/AMQ-4338
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Priority: Minor
> Attachments: AMQ-4338A.patch, AMQ-4338.patch
>
>
> MQTTSSLTest has multiple different test cases (including 
> testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, 
> testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, 
> testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, 
> testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the 
> provider.connect() call in initializeConnection() as shown in the stacktrace 
> below. 
> Another problem with this test is it was giving a misleading error when run 
> under Hudson, showing that the test that followed it (MQTTTest) was failing 
> instead.  I think this was because of the way it was using 
> AutoFailTestSupport.  I will attach a patch which removes that and uses 
> timeouts on @Test annotations instead.
> testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest)
>   Time elapsed: 30.004 sec  <<< ERROR!
> java.lang.Exception: test timed out after 3 milliseconds
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.fusesource.mqtt.client.Promise.await(Promise.java:88)
> at 
> org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49)
> at 
> org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39)
> at 
> org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60)
> Results :
> Tests in error:
>   
> MQTTSSLTest>AbstractMQTTTest.testSendAndReceiveLargeMessages:247->initializeConnection:60
>  »

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585915#comment-13585915
 ] 

Timothy Bish commented on AMQ-4336:
---

Can you attach some broker logs 

> SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
> message producer
> --
>
> Key: AMQ-4336
> URL: https://issues.apache.org/jira/browse/AMQ-4336
> Project: ActiveMQ
>  Issue Type: Bug
> Environment: ActiveMQ 5.6,NMS,C#
>Reporter: Tamilmaran
>Priority: Blocker
> Attachments: activemq.xml, WAPSimulator.rar
>
>
> I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
> a durable subscriber in server side but not sure about its speed to consume 
> all the messages in same rate as well as the producer.
> But after an hour, 'Connection is already closed' error is logged on producer 
> side.
> On ActiveMQ side, Following error has been logged.
> 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
> tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
> org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
> Transport: ssl:///10.2.44.73:59355
> 10.2.44.73-> Bulk MSG producer IP
> ActiveMQ is using File based cursor and producer control.
> Attached activeMQ config file and producer app(WAPSimulator)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Lucille Wilson (JIRA)]

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

Lucille Wilson updated AMQ-4335:


Attachment: AMQ4335Test4_With2mbMessage.zip

The max frame size is set to 1mb, however the message is 2mb.   The expected 
result is an error.  However, the message goes through.  All overrides of 
maxFrameSize are ignored.  Only the default maxFrameSize is respected.

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, 
> AMQ4335Test4_With2mbMessage.zip, AMQ4335Test.java, AMQ4335Test.java, 
> AMQ4335Test.java, amq4335.xml, amq4335.xml, BugInActivemq.zip, 
> max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Lucille Wilson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585896#comment-13585896
 ] 

Lucille Wilson commented on AMQ-4335:
-

I set the maxFrameSize in ACTIVEMQ_HOME/conf/activemq.xml to 1 mb.
Then I created a junit test class which created a 2 mb message.  I expect that 
if my setting of maxframesize is respected the message will produce an error 
saying frame size of 2mb is larger than the max allowed of 1mb.

However, the message was enqueued. 

Please see AMQ4335Test4_With2mbMessage.zip.

I believe I have proven that Activemq has hard-coded a 100mb limit in the 
maxframesize and that any overrides set are ignored.  We'd like Activemq to fix 
this bug, please.  Please let us know when the bug is fixed and where to 
download the software.

Lucille Wilson

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, AMQ4335Test.java, 
> AMQ4335Test.java, AMQ4335Test.java, amq4335.xml, amq4335.xml, 
> BugInActivemq.zip, max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB

[Lucille Wilson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585879#comment-13585879
 ] 

Lucille Wilson commented on AMQ-4335:
-

tcp://0.0.0.0:61616

> Cannot set maxFrameSize greater than 100MB
> --
>
> Key: AMQ-4335
> URL: https://issues.apache.org/jira/browse/AMQ-4335
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Windows 2008 R2
>Reporter: Pat Flaherty
> Attachments: AMQ4335Test3_WithLargeGeneratedString.zip, 
> AMQ4335_Test4_regularRunThroughOurApplication.zip, AMQ4335Test.java, 
> AMQ4335Test.java, AMQ4335Test.java, amq4335.xml, amq4335.xml, 
> BugInActivemq.zip, max-frame-size-test.zip
>
>
> Trying to send JSON messages greater then 100MB and I receive the error:
> Transport Connection to: tcp://192.168.10.1:55823 failed: 
> java.io.IOException: Frame size of 140 MB larger
>  than max allowed 100 MB
> I tried increasing the frame size in 5.8.0 as follows:
> 
> 
>  uri="tcp://192.168.10.1:61616?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireformat.maxFrameSize=157286400"/>
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-1722) Consumer not detectecting broker restart/stopping

[Ronny H. Ringen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585873#comment-13585873
 ] 

Ronny H. Ringen commented on AMQ-1722:
--

Did using the inactivity monitor resolve the issue? I have the same problem (on 
amq 5.6.0 (broker is 5.5.1)) and adding the inactivity monitor had noe effect.

> Consumer not detectecting  broker restart/stopping
> --
>
> Key: AMQ-1722
> URL: https://issues.apache.org/jira/browse/AMQ-1722
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.1.0
> Environment: Windows XP, eclipse 3.2
>Reporter: Carel-Andre Gåsemyr
> Fix For: NEEDS_REVIEWED
>
>
> I have a test to assure a message consumer is still consuming messages after 
> a central broker restart, using 
> org.springframework.jms.listener.DefaultMessageListenerContainer.
> The channel never detects the broker shutting down. 
> org.apache.activemq.MessageDispatchChannel.isClosed() returns "false" when 
> org.apache.activemq.ActiveMQMessageConsumer  is validating the connection.
> I found org.apache.activemq.MessageDispatchChannel.close() is newer called 
> when the broker is stopped. This was working in 5.0.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4122) Lease Database Locker failover broken

[st.h (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585841#comment-13585841
 ] 

st.h commented on AMQ-4122:
---

Gary, I can confirm expected behavior when applying your changes. Thanks. 
However, I would suggest the following changes:
- modify the documentation to show the correct configuration. currently it 
shows {{lockKeepAlivePeriod="1"  lockAcquireSleepInterval="5000"}}, which 
has been the config I used for the tests.
- in case lockAcquireSleepInterval < lockKeepAlivePeriod, at least log a 
warning.

> Lease Database Locker failover broken
> -
>
> Key: AMQ-4122
> URL: https://issues.apache.org/jira/browse/AMQ-4122
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
> Environment: Java 7u9, SUSE 11, Mysql
>Reporter: st.h
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: activemq-kyle.xml, activemq.xml, activemq.xml, 
> AMQ4122.patch, mysql.log
>
>
> We are using ActiveMQ 5.7.0 together with a mysql database and could not 
> observe correct failover behavior with lease database locker.
> It seems that there is a race condition, which prevents the correct failover 
> procedure.
> We noticed that when starting up two instances, both instance are becoming 
> master.
> We did several test, including the following and could not observe intended 
> functionality:
> - shutdown all instances
> - manipulate database lock that one node has lock and set expiry time in 
> distance future
> - start up both instances. both instances are unable to acquire lock, as the 
> lock hasn't expired, which should be correct behavior.
> - update the expiry time in database, so that the lock is expired.
> - first instance notices expired lock and becomes master
> - when second instance checks for lock, it also updates the database and 
> becomes master.
> To my understanding the second instance should not be able to update the 
> lock, as it is held by the first instance and should not be able to become 
> master.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (AMQ-4344) Add OSGi metadata

[Jean-Pierre Bergamin (JIRA)]

Jean-Pierre Bergamin created AMQ-4344:
-

 Summary: Add OSGi metadata
 Key: AMQ-4344
 URL: https://issues.apache.org/jira/browse/AMQ-4344
 Project: ActiveMQ
  Issue Type: Wish
  Components: Apollo
Reporter: Jean-Pierre Bergamin
Priority: Minor


Convert the apollo jars to OSGi bundles by adding metadata to the MANIFEST.MF 
files.

Please see 
http://activemq.2283324.n4.nabble.com/OSGi-support-for-Apollo-td4663953.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (AMQ-4341) activemq-broker feature can not be installed when OBR is enabled

[Gary Tully (JIRA)]

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

Gary Tully reassigned AMQ-4341:
---

Assignee: Gary Tully

> activemq-broker feature can not be installed when OBR is enabled
> 
>
> Key: AMQ-4341
> URL: https://issues.apache.org/jira/browse/AMQ-4341
> Project: ActiveMQ
>  Issue Type: Task
>Affects Versions: 5.8.0
>Reporter: Gert Vanthienen
>Assignee: Gary Tully
> Attachments: AMQ-4341.patch
>
>
> While trying to integrate ActiveMQ 5.8.0 into ServiceMix 5.0.0, I bumped into 
> 2 problems with the features descriptor on a Karaf-based container that has 
> OBR resolution enabled for the Features service:
> * the activemq-http fragment is referring to a Fragment-Host called 
> {{org.apache.activemq.activemq-core}}, which no longer exists
> * the xbean-spring bundle is marked with {{dependency=true}} but no other 
> bundle is importing any packages from it, so it does not get installed - 
> since {{activemq-karaf}} does need those packages to work properly, the 
> easiest solution is probably to add a proper Import-Package header to that 
> bundle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4122) Lease Database Locker failover broken

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585816#comment-13585816
 ] 

Gary Tully commented on AMQ-4122:
-

@SouNayi  - thanks for the feedback. on {quote}The cause is that 
LeaseDatabaseLocker always succeed updating the broker name (the owner of the 
lease lock) by later lease time in contrast to the current lease owner.{quote}

Can you make a variant of 
https://fisheye6.atlassian.com/viewrep/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/store/jdbc/LeaseDatabaseLockerTest.java
 that shows the problem? I don't see a problem against derby in the unit test. 
Note: in the unit test there is no periodic call to keepalive.
The intent of the update to acquire a lock checks the TIME value against 
current time and sets it to obtain the lease. It should (and does) fail if the 
lease is still valid. ie: the time is set to a value in the 
future.https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#

> Lease Database Locker failover broken
> -
>
> Key: AMQ-4122
> URL: https://issues.apache.org/jira/browse/AMQ-4122
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
> Environment: Java 7u9, SUSE 11, Mysql
>Reporter: st.h
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: activemq-kyle.xml, activemq.xml, activemq.xml, 
> AMQ4122.patch, mysql.log
>
>
> We are using ActiveMQ 5.7.0 together with a mysql database and could not 
> observe correct failover behavior with lease database locker.
> It seems that there is a race condition, which prevents the correct failover 
> procedure.
> We noticed that when starting up two instances, both instance are becoming 
> master.
> We did several test, including the following and could not observe intended 
> functionality:
> - shutdown all instances
> - manipulate database lock that one node has lock and set expiry time in 
> distance future
> - start up both instances. both instances are unable to acquire lock, as the 
> lock hasn't expired, which should be correct behavior.
> - update the expiry time in database, so that the lock is expired.
> - first instance notices expired lock and becomes master
> - when second instance checks for lock, it also updates the database and 
> becomes master.
> To my understanding the second instance should not be able to update the 
> lock, as it is held by the first instance and should not be able to become 
> master.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (AMQ-4122) Lease Database Locker failover broken

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584596#comment-13584596
 ] 

Gary Tully edited comment on AMQ-4122 at 2/25/13 11:57 AM:
---

@st.h - thanks for the slq log.
>From looking at 
>https://issues.apache.org/jira/secure/attachment/12570319/mysql.log, it looks 
>like a configuration problem.
node-h03-ap21 is obtaining a 5s lease that it renews every 10s. So there is a s 
period when the lease is available to others.

It needs to obtain a 10 second lease and update it every 5 seconds. So that a 
second (slave) broker always sees time > now when it attempts an update as part 
of an acquire.

You need:
{code}

   ..
   
 
   
{code}
lockAcquireSleepInterval is the lease duration, lockKeepAlivePeriod is the 
lease renew period. On a renew, the lease is extended by the 
lockAcquireSleepInterval (lease duration). So a master is always 
(lockAcquireSleepInterval - lockKeepAlivePeriod) ahead with its lease.
In short, ensure: lockAcquireSleepInterval > lockKeepAlivePeriod.

Can you verify this.
I think it may also makes sense to add lease related attributes to this locker. 
leaseDuration, leaseRenewPeriod so that it is a little more intuitive and 
obvious that the leaseDuration > leaseRenewPeriod


  was (Author: gtully):
@SouNayi - thanks for the slq log.
>From looking at 
>https://issues.apache.org/jira/secure/attachment/12570319/mysql.log, it looks 
>like a configuration problem.
node-h03-ap21 is obtaining a 5s lease that it renews every 10s. So there is a s 
period when the lease is available to others.

It needs to obtain a 10 second lease and update it every 5 seconds. So that a 
second (slave) broker always sees time > now when it attempts an update as part 
of an acquire.

You need:
{code}

   ..
   
 
   
{code}
lockAcquireSleepInterval is the lease duration, lockKeepAlivePeriod is the 
lease renew period. On a renew, the lease is extended by the 
lockAcquireSleepInterval (lease duration). So a master is always 
(lockAcquireSleepInterval - lockKeepAlivePeriod) ahead with its lease.
In short, ensure: lockAcquireSleepInterval > lockKeepAlivePeriod.

Can you verify this.
I think it may also makes sense to add lease related attributes to this locker. 
leaseDuration, leaseRenewPeriod so that it is a little more intuitive and 
obvious that the leaseDuration > leaseRenewPeriod

  
> Lease Database Locker failover broken
> -
>
> Key: AMQ-4122
> URL: https://issues.apache.org/jira/browse/AMQ-4122
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.7.0
> Environment: Java 7u9, SUSE 11, Mysql
>Reporter: st.h
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: activemq-kyle.xml, activemq.xml, activemq.xml, 
> AMQ4122.patch, mysql.log
>
>
> We are using ActiveMQ 5.7.0 together with a mysql database and could not 
> observe correct failover behavior with lease database locker.
> It seems that there is a race condition, which prevents the correct failover 
> procedure.
> We noticed that when starting up two instances, both instance are becoming 
> master.
> We did several test, including the following and could not observe intended 
> functionality:
> - shutdown all instances
> - manipulate database lock that one node has lock and set expiry time in 
> distance future
> - start up both instances. both instances are unable to acquire lock, as the 
> lock hasn't expired, which should be correct behavior.
> - update the expiry time in database, so that the lock is expired.
> - first instance notices expired lock and becomes master
> - when second instance checks for lock, it also updates the database and 
> becomes master.
> To my understanding the second instance should not be able to update the 
> lock, as it is held by the first instance and should not be able to become 
> master.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is unstable: ActiveMQ-Java7 #148

[Apache Jenkins Server]

See 

Jenkins build is back to normal : ActiveMQ-Java7 » ActiveMQ :: Client #148

[Apache Jenkins Server]

See 

[jira] [Commented] (AMQ-4341) activemq-broker feature can not be installed when OBR is enabled

[Gert Vanthienen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585723#comment-13585723
 ] 

Gert Vanthienen commented on AMQ-4341:
--

Instead of removing the dependency flags from xbean-spring and the JMS 
specification, wouldn't it be better to ensure the activemq-osgi bundle imports 
those required packages?  That would trigger the installation of those bundles 
too, but it would also avoid installing a second version of xbean-spring if a 
suitable one is already available.

> activemq-broker feature can not be installed when OBR is enabled
> 
>
> Key: AMQ-4341
> URL: https://issues.apache.org/jira/browse/AMQ-4341
> Project: ActiveMQ
>  Issue Type: Task
>Affects Versions: 5.8.0
>Reporter: Gert Vanthienen
> Attachments: AMQ-4341.patch
>
>
> While trying to integrate ActiveMQ 5.8.0 into ServiceMix 5.0.0, I bumped into 
> 2 problems with the features descriptor on a Karaf-based container that has 
> OBR resolution enabled for the Features service:
> * the activemq-http fragment is referring to a Fragment-Host called 
> {{org.apache.activemq.activemq-core}}, which no longer exists
> * the xbean-spring bundle is marked with {{dependency=true}} but no other 
> bundle is importing any packages from it, so it does not get installed - 
> since {{activemq-karaf}} does need those packages to work properly, the 
> easiest solution is probably to add a proper Import-Package header to that 
> bundle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira