Jenkins build is unstable: ActiveMQ » ActiveMQ :: AMQP #1306

[Apache Jenkins Server]

See 

[jira] [Commented] (AMQ-1126) The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs

[Jason Shepherd (JIRA)]

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

Jason Shepherd commented on AMQ-1126:
-

Reported on Enterprise MQ 7.1.0 

https://issues.apache.org/jira/browse/AMQ-1126

> The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
> -
>
> Key: AMQ-1126
> URL: https://issues.apache.org/jira/browse/AMQ-1126
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JCA Container
>Affects Versions: 4.0.1
> Environment: Java 1.4.2_08
> JBoss 4.0.4
> ActiveMQ 4.0.1
>Reporter: John Robinson
> Fix For: NEEDS_REVIEWED
>
> Attachments: amq_reproducer.zip, msg-group-test.zip
>
>
> Integrate AMQ into JBoss using the data source, and resource adapter.  Create 
> an outbound queue and an MDB with a pool size of 100.  Dispatch several 
> messages to the outbound queue, setting the JMSXGroupID property on the 
> message to be the same value each time.  In the MDB's onMessage method print 
> out the MDBs toString (don't override toString) and you should see something 
> that looks like:
> OutQueueProcessorBean@19a7266
> Observe two things:
> a) Many messages are processed in parallel
> b) Many different values will occur after the @ in the above message, 
> denoting that more than on MDB instance is being handed messages.
> The correct behavior would be to dispatch messages with the same group id to 
> the same MDB instance in sequence.  This would allow messages from different 
> groups to be processed in parallel, but messages in any one group would be 
> processed serially, in the order in which they were placed into the queue.

--
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-1126) The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs

[Jason Shepherd (JIRA)]

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

Jason Shepherd edited comment on AMQ-1126 at 6/5/13 12:51 AM:
--

Reported on Enterprise MQ 7.1.0 

https://fusesource.com/issues/browse/ENTMQ-261

  was (Author: jshepher):
Reported on Enterprise MQ 7.1.0 

https://issues.apache.org/jira/browse/AMQ-1126
  
> The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
> -
>
> Key: AMQ-1126
> URL: https://issues.apache.org/jira/browse/AMQ-1126
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JCA Container
>Affects Versions: 4.0.1
> Environment: Java 1.4.2_08
> JBoss 4.0.4
> ActiveMQ 4.0.1
>Reporter: John Robinson
> Fix For: NEEDS_REVIEWED
>
> Attachments: amq_reproducer.zip, msg-group-test.zip
>
>
> Integrate AMQ into JBoss using the data source, and resource adapter.  Create 
> an outbound queue and an MDB with a pool size of 100.  Dispatch several 
> messages to the outbound queue, setting the JMSXGroupID property on the 
> message to be the same value each time.  In the MDB's onMessage method print 
> out the MDBs toString (don't override toString) and you should see something 
> that looks like:
> OutQueueProcessorBean@19a7266
> Observe two things:
> a) Many messages are processed in parallel
> b) Many different values will occur after the @ in the above message, 
> denoting that more than on MDB instance is being handed messages.
> The correct behavior would be to dispatch messages with the same group id to 
> the same MDB instance in sequence.  This would allow messages from different 
> groups to be processed in parallel, but messages in any one group would be 
> processed serially, in the order in which they were placed into the queue.

--
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-4533) Messages stuck in queue with redelivered=true

[Jason Shepherd (JIRA)]

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

Jason Shepherd edited comment on AMQ-4533 at 6/5/13 12:17 AM:
--

This reproducer is basically a reproduction of a production scenario, and it 
needs to be like this, because its the only way we've found to replication the 
issue. If we break down what happens in the test case, hopefully you'll 
understand why we need so many things going on.

Step 2 in the test case is critial for reproducing the problem. It simulates 
slow cusomer, with threads hung, or a slow database operation. Without this 
slow consumer, the test completes very fast, and we don't see the problem. 

The test simulates the production environment where the broker is under heavy 
load. In the test case there is heavy load on SOME_TEST_QUEUE, all of which 
uses separate connections pools, message listeners, and latches. Whereas the 
critical messages for the test case are on INPUT_QUEUE, and RECEIPT_QUEUE, 
which use OtherMessageListener, and onOtherMessageLatch.

This test case is the only evidence of a problem which has been plaguing our 
production environment for years.

Here is how the TC works:

1) start AMQ brokers

2) start spring consumer for consumming from INPUT_QUEUE and putting receipts 
to RECEIPT_QUEUE
This consumer is processing first message for ever.
   if (isStuckOld!=isStuck) {
log4jLogger.info("sleep for eternity");
Thread.sleep(1);
 }  
and next 49 messages longer /30 seconds/ than rest of 1000 msgs.

if (nrProcessed<50) {
Thread.sleep(3);
}

The reason for it is to simulate some slow & stuck consumers which we can 
notice on production.

3) run heavy traffic to SOME.TEST.QUEUE 
a) put 100 messages using 50 threads to broker 1

sendInThreads(QUEUE_NAME, 50, 50, DeliveryMode.NON_PERSISTENT,getUrl1(),1);
sendInThreads(QUEUE_NAME, 50, 50, DeliveryMode.PERSISTENT,getUrl1(),1);

b) get 90 messages in 200 listening threads from broker 2 using 
OtherMessageListener

listenInThreads(QUEUE_NAME, 90, 200,getUrl2(), mListener, otherConnections);

However we do not wait on latches as it is not important. This is traffic to 
simulate heavy load only - not necessary to count them.

4) send traffic to INPUT_QUEUE in 10 threads on broker 1 which triggers our 
spring consumer from step 2 to start consuming and to send output messages to 
RECEIPT_QUEUE /one receipt message sent to RECEIPT_QUEUE for one message 
consumed from INPUT_QUEUE/.

CountDownLatch latch1=sendInThreads(queueName, msgCount, 
threadCount, persistance,getUrl1(),500);

The latch1 is checked later in the step 6 to ensure we had all 1000 messages 
sent there.

5) listen on RECEIPT_QUEUE in 10 threads on broker 2 using MainMessageListener 
with onMainMessageLatch set to 999 /one message should be stuck on consummer 
forever by TC design/

CountDownLatch latch=listenInThreads(queueName, msgCount, 
threadCount,getUrl2(),msgListener,connections);

6) wait for latches - because of heavy load we had to set the timeout long 
enough /here 1000 seconds/ to give the system the chance to process all 
messages from INPUT_QUEUE /the processing might be very slow because of heavy 
load/
onMainMessageLatch.await(1000, TimeUnit.SECONDS);
and also we check if all messages were put into INPUT_QUEUE for processing
latch1.await(msgCount/10, TimeUnit.SECONDS); // .MINUTES

7) check assertions for INPUT_QUEUE and RECEIPT_QUEUE - they should be empty

queueName = INPUT_QUEUE;

queueSize1=queueSize(brokerService1, queueName);
queueSize2=queueSize(brokerService2, queueName);

Assert.assertEquals("Still messages in "+queueName,0, 
queueSize1+queueSize2);

queueName = RECEIPT_QUEUE;

queueSize1=queueSize(brokerService1, queueName);
queueSize2=queueSize(brokerService2, queueName);

Assert.assertEquals("Still messages in "+queueName,0, 
queueSize1+queueSize2);   


8) close AMQ brokers


  was (Author: jshepher):
This reproducer is basically a reproduction of a production scenario, and 
it needs to be like this, because its the only way we've found to replication 
the issue. If we break down what happens in the test case, hopefully you'll 
understand why we need so many things going on.

Step 2 in the test case is critial for reproducing the problem. It simulates 
slow cusomer, with threads hung, or a slow database operation. Without this 
slow consumer, the test completes very fast, and we don't see the problem. 

T

[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true

[Jason Shepherd (JIRA)]

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

Jason Shepherd commented on AMQ-4533:
-

This reproducer is basically a reproduction of a production scenario, and it 
needs to be like this, because its the only way we've found to replication the 
issue. If we break down what happens in the test case, hopefully you'll 
understand why we need so many things going on.

Step 2 in the test case is critial for reproducing the problem. It simulates 
slow cusomer, with threads hung, or a slow database operation. Without this 
slow consumer, the test completes very fast, and we don't see the problem. 

The test simulates the production environment where the broker is under heavy 
load. In the test case there is head load on SOME_TEST_QUEUE, all of which uses 
seperate connections pools, message listeners, and latches. Whereas the crital 
messages for the test case are on INPUT_QUEUE, and RECEIPT_QUEUE, which use 
OtherMessageListener, and onOtherMessageLatch.

This test case is the only evidence of a problem which has been plauging our 
production environment for years.

Here is how the TC works:

1) start AMQ brokers

2) start spring consumer for consumming from INPUT_QUEUE and putting receipts 
to RECEIPT_QUEUE
This consumer is processing first message for ever.
   if (isStuckOld!=isStuck) {
log4jLogger.info("sleep for eternity");
Thread.sleep(1);
 }  
and next 49 messages longer /30 seconds/ than rest of 1000 msgs.

if (nrProcessed<50) {
Thread.sleep(3);
}

The reason for it is to simulate some slow & stuck consumers which we can 
notice on production.

3) run heavy traffic to SOME.TEST.QUEUE 
a) put 100 messages using 50 threads to broker 1

sendInThreads(QUEUE_NAME, 50, 50, DeliveryMode.NON_PERSISTENT,getUrl1(),1);
sendInThreads(QUEUE_NAME, 50, 50, DeliveryMode.PERSISTENT,getUrl1(),1);

b) get 90 messages in 200 listening threads from broker 2 using 
OtherMessageListener

listenInThreads(QUEUE_NAME, 90, 200,getUrl2(), mListener, otherConnections);

However we do not wait on latches as it is not important. This is traffic to 
simulate heavy load only - not necessary to count them.

4) send traffic to INPUT_QUEUE in 10 threads on broker 1 which triggers our 
spring consumer from step 2 to start consuming and to send output messages to 
RECEIPT_QUEUE /one receipt message sent to RECEIPT_QUEUE for one message 
consumed from INPUT_QUEUE/.

CountDownLatch latch1=sendInThreads(queueName, msgCount, 
threadCount, persistance,getUrl1(),500);

The latch1 is checked later in the step 6 to ensure we had all 1000 messages 
sent there.

5) listen on RECEIPT_QUEUE in 10 threads on broker 2 using MainMessageListener 
with onMainMessageLatch set to 999 /one message should be stuck on consummer 
forever by TC design/

CountDownLatch latch=listenInThreads(queueName, msgCount, 
threadCount,getUrl2(),msgListener,connections);

6) wait for latches - because of heavy load we had to set the timeout long 
enough /here 1000 seconds/ to give the system the chance to process all 
messages from INPUT_QUEUE /the processing might be very slow because of heavy 
load/
onMainMessageLatch.await(1000, TimeUnit.SECONDS);
and also we check if all messages were put into INPUT_QUEUE for processing
latch1.await(msgCount/10, TimeUnit.SECONDS); // .MINUTES

7) check assertions for INPUT_QUEUE and RECEIPT_QUEUE - they should be empty

queueName = INPUT_QUEUE;

queueSize1=queueSize(brokerService1, queueName);
queueSize2=queueSize(brokerService2, queueName);

Assert.assertEquals("Still messages in "+queueName,0, 
queueSize1+queueSize2);

queueName = RECEIPT_QUEUE;

queueSize1=queueSize(brokerService1, queueName);
queueSize2=queueSize(brokerService2, queueName);

Assert.assertEquals("Still messages in "+queueName,0, 
queueSize1+queueSize2);   


8) close AMQ brokers


> Messages stuck in queue with redelivered=true
> -
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
>Reporter: Jason Shepherd
> Attachments: AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, 
> kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used 

[jira] [Commented] (AMQ-4569) Stomp inactivity timeout takes significantly longer than specified

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4569:
---

Things are working as designed.  The read checks are meant to be lenient in 
order to prevent breaking off a client to quickly in case of large message 
sends.  If you want more controlled inactivity checks you need a STOMP v1.1+ 
client with write checks which will detect broken sockets on write. 

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4569:
-

Attachment: activemq.log

Attaching another activemq.log excerpt. This one should cover startup of AMQ 
thru connection of a client that does not do any subsequent reading thru the 
disconnection of that client after 15 minutes instead of 5 minutes of 
inactivity.

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-3603) STOMP 1.1 introduced the heartBeat header implemented by the inactivity monitor, would be nice to have this option for stomp 1.0

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-3603:
--

This feature does work, however timeout appears to take 3 times longer than 
specified. I created a new issue AMQ-4569 for this problem.

> STOMP 1.1 introduced the heartBeat header implemented by the inactivity 
> monitor, would be nice to have this option for stomp 1.0
> 
>
> Key: AMQ-3603
> URL: https://issues.apache.org/jira/browse/AMQ-3603
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.5.1
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: inactivity, monitor, stomp
> Fix For: 5.6.0
>
>
> Stomp 1.0 does not provide for an inactivity monitor. A client connect that 
> stays idle will remain active on the broker indefinitely. With 1.1, the 
> inactivity monitor has come into play in response to the heartBeat header. 
> For 1.0 clients we need a way to indicate that there is a default heartBeat 
> header, so a broker readTimeout and no expectation of a writeTimeout.
> Providing a transport option for stomp like 
> {{stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0}} would be nice. In the 
> absence of a heartbeat header, as in the stomp 1.0 case, this default value 
> would cause an InactivityMonitor with readCheck of 500 to be installed on 
> each new broker stomp transport connection.
> Any client that remains inactive for more than 5 seconds will have their 
> broker connection closed.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4569:
--

I forgot to turn off some other processing that touches that AMQ instance. I'll 
run it again with just the test client.

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4569:
--

Except that my test client, which connects and subscribes but then sleeps 
didn't disconnect until after 15 minutes. I'll grab the rest of the log and 
attach it.

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-3603) STOMP 1.1 introduced the heartBeat header implemented by the inactivity monitor, would be nice to have this option for stomp 1.0

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-3603:
---

You'll need to produce some test that shows this to be the case. 

> STOMP 1.1 introduced the heartBeat header implemented by the inactivity 
> monitor, would be nice to have this option for stomp 1.0
> 
>
> Key: AMQ-3603
> URL: https://issues.apache.org/jira/browse/AMQ-3603
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.5.1
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: inactivity, monitor, stomp
> Fix For: 5.6.0
>
>
> Stomp 1.0 does not provide for an inactivity monitor. A client connect that 
> stays idle will remain active on the broker indefinitely. With 1.1, the 
> inactivity monitor has come into play in response to the heartBeat header. 
> For 1.0 clients we need a way to indicate that there is a default heartBeat 
> header, so a broker readTimeout and no expectation of a writeTimeout.
> Providing a transport option for stomp like 
> {{stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0}} would be nice. In the 
> absence of a heartbeat header, as in the stomp 1.0 case, this default value 
> would cause an InactivityMonitor with readCheck of 500 to be installed on 
> each new broker stomp transport connection.
> Any client that remains inactive for more than 5 seconds will have their 
> broker connection closed.

--
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-3603) STOMP 1.1 introduced the heartBeat header implemented by the inactivity monitor, would be nice to have this option for stomp 1.0

[Karen Morrissey (JIRA)]

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

Karen Morrissey edited comment on AMQ-3603 at 6/4/13 10:29 PM:
---

This feature does work, however timeout appears to take 3 times longer than 
specified. I created a new issue AMQ-4569 for this problem. I endorse closing 
the issue.

  was (Author: kamorrissey):
This feature does work, however timeout appears to take 3 times longer than 
specified. I created a new issue AMQ-4569 for this problem.
  
> STOMP 1.1 introduced the heartBeat header implemented by the inactivity 
> monitor, would be nice to have this option for stomp 1.0
> 
>
> Key: AMQ-3603
> URL: https://issues.apache.org/jira/browse/AMQ-3603
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.5.1
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: inactivity, monitor, stomp
> Fix For: 5.6.0
>
>
> Stomp 1.0 does not provide for an inactivity monitor. A client connect that 
> stays idle will remain active on the broker indefinitely. With 1.1, the 
> inactivity monitor has come into play in response to the heartBeat header. 
> For 1.0 clients we need a way to indicate that there is a default heartBeat 
> header, so a broker readTimeout and no expectation of a writeTimeout.
> Providing a transport option for stomp like 
> {{stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0}} would be nice. In the 
> absence of a heartbeat header, as in the stomp 1.0 case, this default value 
> would cause an InactivityMonitor with readCheck of 500 to be installed on 
> each new broker stomp transport connection.
> Any client that remains inactive for more than 5 seconds will have their 
> broker connection closed.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4569:
---

Things seem to be working fine, stomp client will remain connected since the 
broker is reporting:

{noformat}
2013-06-04 16:11:56,011 | TRACE | A receive is in progress | 
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ 
InactivityMonitor ReadCheckTimer
{noformat}


> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4569:
-

Attachment: activemq.log

Attaching a newer log excerpt with TRACE turned on. Couldn't find the place in 
the log where AMQ started, so I began the excerpt where AMQ was stopped.

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4569:
---

You can further debug the inactivity monitor by setting these values for the 
AMQ logging which will show you the monitor checking the client. 

{noformat}
log4j.logger.org.apache.activemq.transport=TRACE
{noformat}

You should see something along these lines.

{noformat}
2013-06-04 18:02:09,204 [0.1:33780@51836] - DEBUG StompInactivityMonitor
 - Stomp Inactivity Monitor read check: 5000, write check: 0
2013-06-04 18:02:09,205 [0.1:33780@51836] - DEBUG ProtocolConverter 
 - Stomp Connect heartbeat conf RW[5000,0]
2013-06-04 18:02:09,205 [ ReadCheckTimer] - TRACE AbstractInactivityMonitor 
 - A receive is in progress
2013-06-04 18:02:14,206 [ ReadCheckTimer] - DEBUG AbstractInactivityMonitor 
 - 5001 ms elapsed since last read check.
2013-06-04 18:02:14,206 [ ReadCheckTimer] - TRACE AbstractInactivityMonitor 
 - A receive is in progress
2013-06-04 18:02:19,206 [ ReadCheckTimer] - DEBUG AbstractInactivityMonitor 
 - 5000 ms elapsed since last read check.
2013-06-04 18:02:19,206 [ ReadCheckTimer] - TRACE AbstractInactivityMonitor 
 - Message received since last read check, resetting flag: 
2013-06-04 18:02:24,206 [ ReadCheckTimer] - DEBUG AbstractInactivityMonitor 
 - 5000 ms elapsed since last read check.
2013-06-04 18:02:24,206 [ ReadCheckTimer] - DEBUG AbstractInactivityMonitor 
 - No message received since last read check for tcp:///127.0.0.1:33780@51836. 
Throwing InactivityIOException.
2013-06-04 18:02:24,210 [yMonitor Worker] - DEBUG AbstractInactivityMonitor 
 - Running ReadCheck[tcp://127.0.0.1:33780]
{noformat}

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4569:
-

Attachment: activemq.log

Attaching an activemq.log excerpt of a clean run of ActiveMQ followed by a 
STOMP client connection.

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log
>
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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] [Deleted] (AMQCPP-486) delete account

[Timothy Bish (JIRA)]

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

Timothy Bish deleted AMQCPP-486:



> delete account
> --
>
> Key: AMQCPP-486
> URL: https://issues.apache.org/jira/browse/AMQCPP-486
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>Reporter: rachelle brown
>Assignee: Timothy Bish
>


--
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] (AMQCPP-486) delete account

[rachelle brown (JIRA)]

rachelle brown created AMQCPP-486:
-

 Summary: delete account
 Key: AMQCPP-486
 URL: https://issues.apache.org/jira/browse/AMQCPP-486
 Project: ActiveMQ C++ Client
  Issue Type: Bug
Reporter: rachelle brown
Assignee: Timothy Bish




--
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-4569) Stomp inactivity timeout takes significantly longer than specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4569:
-

Summary: Stomp inactivity timeout takes significantly longer than specified 
 (was: Stomp inactivity timeout takes significantly longer specified)

> Stomp inactivity timeout takes significantly longer than specified
> --
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4569) Stomp inactivity timeout takes significantly longer specified

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4569:
--

Due to work priorities, it may take me a while to get back with the requested 
information.

> Stomp inactivity timeout takes significantly longer specified
> -
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4573:
--

I haven't worked with snapshots before. I looked at the download area and I'm 
not sure what to download.

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store, stomp, Transport
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4573:
---

https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.9-SNAPSHOT/

Download the tar.gz or zip depending on your OS. 

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store, stomp, Transport
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4573:
--

Do I download 
org/apache/activemq/activemq-broker/5.9-SNAPSHOT/activemq-broker-5.9-20130603.145847-73.jar
 ?

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store, stomp, Transport
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4573:
-

Component/s: Message Store

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, Message Store
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4569) Stomp inactivity timeout takes significantly longer specified

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4569:
---

You should enable debug logging on the broker and post the logs after starting 
a clean broker and connecting a client, this should log what values are being 
used to configure the inactivity monitor.

> Stomp inactivity timeout takes significantly longer specified
> -
>
> Key: AMQ-4569
> URL: https://issues.apache.org/jira/browse/AMQ-4569
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
> Environment: Windows 7, JRE 7.
>Reporter: Karen Morrissey
>Priority: Minor
>  Labels: heartbeat, inactivity, stomp
>
> When I specify a timeout using a connector like the following to get a 
> 5-minute idle timeout
> {code:xml}
>  uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=30,0"/>
> {code}
> It takes 15 minutes for it to time out. I tried one previously at 90 (15 
> minutes), and it had not timed out after 35 minutes, when I had to leave.
> So, it appears the timeout takes 3 times longer than specified. I find it 
> suspicious that there is a call somewhere I saw in the code that divides the 
> timeout period by 3.

--
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-4573) AMQ not starting when using default heart beat

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4573:
---

Recommend you try with a recent 5.9-SNAPSHOT to get all the current KahaDB 
fixes. 

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store, stomp, Transport
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4573:
-

Labels: heartbeat inactivity index kahadb stomp  (was: heartbeat inactivity 
stomp)

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4573:
-

Component/s: (was: Broker)
 Transport
 stomp

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store, stomp, Transport
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, index, kahadb, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4573:
-

Attachment: activemq.log
activemq.xml

Attached the activemq.xml with the offending transport connector commented out. 
Also attached the current activemq.log.

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, stomp
> Attachments: activemq.log, activemq.xml
>
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey commented on AMQ-4573:
--

I should add that this problem does not appear in a different AMQ instance, 
running on Windows 7 64-bit.

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, stomp
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

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

Karen Morrissey updated AMQ-4573:
-

Labels: heartbeat inactivity stomp  (was: )

> AMQ not starting when using default heart beat
> --
>
> Key: AMQ-4573
> URL: https://issues.apache.org/jira/browse/AMQ-4573
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: 5.8.0 on CentOS 5.8 32-bit
>Reporter: Karen Morrissey
>  Labels: heartbeat, inactivity, stomp
>
> AMQ is not starting successfully when I enable a default heart beat for STOMP 
> using
> {code:xml}
>  uri="stomp://0.0.0.0:3037?transport.defaultHeartBeat=30,0"/>
> {code}
> Looking at the log I get repeated messages like the following:
> {code}
> 2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
> org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
> java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
> at 
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
> at 
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
> at 
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
> at 
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
> at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
> at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)
> {code}
> I'm listing this as major, because not setting a default heart beat is not an 
> acceptable workaround for us.

--
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-4573) AMQ not starting when using default heart beat

[Karen Morrissey (JIRA)]

Karen Morrissey created AMQ-4573:


 Summary: AMQ not starting when using default heart beat
 Key: AMQ-4573
 URL: https://issues.apache.org/jira/browse/AMQ-4573
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.8.0
 Environment: 5.8.0 on CentOS 5.8 32-bit
Reporter: Karen Morrissey


AMQ is not starting successfully when I enable a default heart beat for STOMP 
using
{code:xml}

{code}

Looking at the log I get repeated messages like the following:
{code}
2013-06-04 16:46:04,256 | WARN  | Failed to browse Topic: decoded_wwas | 
org.apache.activemq.broker.region.Topic | ActiveMQ Broker[10.0.3.32] Scheduler
java.io.EOFException: Chunk stream does not exist, page: 58 is marked free
at 
org.apache.activemq.store.kahadb.disk.page.Transaction$2.readPage(Transaction.java:470)
at 
org.apache.activemq.store.kahadb.disk.page.Transaction$2.(Transaction.java:447)
at 
org.apache.activemq.store.kahadb.disk.page.Transaction.openInputStream(Transaction.java:444)
at 
org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:420)
at 
org.apache.activemq.store.kahadb.disk.page.Transaction.load(Transaction.java:377)
at 
org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadNode(BTreeIndex.java:262)
at 
org.apache.activemq.store.kahadb.disk.index.BTreeIndex.getRoot(BTreeIndex.java:174)
at 
org.apache.activemq.store.kahadb.disk.index.BTreeIndex.iterator(BTreeIndex.java:232)
at 
org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex$MessageOrderIterator.(MessageDatabase.java:2757)
at 
org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.iterator(MessageDatabase.java:2739)
at 
org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$3.execute(KahaDBStore.java:526)
at 
org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
at 
org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recover(KahaDBStore.java:522)
at 
org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:578)
at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
at org.apache.activemq.broker.region.Topic$6.run(Topic.java:703)
at 
org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
at java.util.TimerThread.mainLoop(Timer.java:534)
at java.util.TimerThread.run(Timer.java:484)
{code}

I'm listing this as major, because not setting a default heart beat is not an 
acceptable workaround for us.

--
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-4572) broken link at http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-4572.
---

Resolution: Fixed

fixed, should work after the next site refresh

> broken link at 
> http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/
> 
>
> Key: AMQ-4572
> URL: https://issues.apache.org/jira/browse/AMQ-4572
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: leonardo kenji shikida
>Priority: Trivial
>
> the link to the config file at 
> http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/
>  is broken from http://activemq.apache.org/jdbc-support.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

Re: Apache Shiro integration status

[Christian Posta]

Awesome, Les, thanks! I will take a look tonight.


On Mon, Jun 3, 2013 at 11:11 AM, Les Hazlewood  wrote:

> I made quite a bit of progress over the weekend.  Here is the result
> of the latest effort:
>
> https://github.com/lhazlewood/activemq/tree/trunk/activemq-shiro
>
> Change log is here:
>
>
> https://github.com/lhazlewood/activemq/commit/be2100ea2c5a421cd21a4c3ae158c65e6e14490f
>
> It works as follows:
>
> The ShiroPlugin installs 2 BrokerFilters at the moment:
>
> - A SubjectFilter which is responsible for constructing and
> associating a Subject instance with Connections.  Downstream filters
> perform actual security checks.
> - An AuthenticationFilter (downstream from the SubjectFilter) that
> enforces client authentication as necessary.  It supports system and
> anonymous connections as well if desired.
>
> I still have to create an AuthorizationFilter (that would be
> downstream from the AuthenticationFilter) that would allow access
> control checks (can you subscribe to a destination or not, etc).
>
> All of this code is tested with 100% class, method and line coverage.
>
> Comments, suggestions and feedback are most welcome.
>
> Cheers,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> PMC Chair, Apache Shiro: http://shiro.apache.org
>



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

Apache Shiro integration status

[Les Hazlewood]

I made quite a bit of progress over the weekend.  Here is the result
of the latest effort:

https://github.com/lhazlewood/activemq/tree/trunk/activemq-shiro

Change log is here:

https://github.com/lhazlewood/activemq/commit/be2100ea2c5a421cd21a4c3ae158c65e6e14490f

It works as follows:

The ShiroPlugin installs 2 BrokerFilters at the moment:

- A SubjectFilter which is responsible for constructing and
associating a Subject instance with Connections.  Downstream filters
perform actual security checks.
- An AuthenticationFilter (downstream from the SubjectFilter) that
enforces client authentication as necessary.  It supports system and
anonymous connections as well if desired.

I still have to create an AuthorizationFilter (that would be
downstream from the AuthenticationFilter) that would allow access
control checks (can you subscribe to a destination or not, etc).

All of this code is tested with 100% class, method and line coverage.

Comments, suggestions and feedback are most welcome.

Cheers,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
PMC Chair, Apache Shiro: http://shiro.apache.org

[jira] [Created] (AMQ-4572) broken link at http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/

[leonardo kenji shikida (JIRA)]

leonardo kenji shikida created AMQ-4572:
---

 Summary: broken link at 
http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/
 Key: AMQ-4572
 URL: https://issues.apache.org/jira/browse/AMQ-4572
 Project: ActiveMQ
  Issue Type: Bug
Reporter: leonardo kenji shikida
Priority: Trivial


the link to the config file at 
http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/resources/META-INF/services/org/apache/activemq/store/jdbc/
 is broken from http://activemq.apache.org/jdbc-support.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] [Commented] (AMQ-4372) WebConsole throw Java Heap Space when browse a queue with more than 100 elements

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4372:
---

You can work around this in the latest 5.9-SNAPSHOT builds if you set the 
maxProducersToAudit Policy value to a high enough value to account for the 
number of producers in your scenario.  

> WebConsole throw Java Heap Space when browse a queue with more than 100 
> elements
> 
>
> Key: AMQ-4372
> URL: https://issues.apache.org/jira/browse/AMQ-4372
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.8.0
> Environment: Linux/Ubuntu
>Reporter: Grégory OLIVER
>  Labels: web-console
> Fix For: 5.9.0
>
>
> I have a standalone installation of activemq.
> When I want to browse a queue with more than 100 elements, the console throw 
> a Java Heap Space, because he try to show all elements in the queue. 
> But when I have 40 elements, the page work well, and i can browse messages.
> It should be interesting to paginate this page, to only show, for example, 
> the first 100 elements.
> The page : 
> http://localhost:8161/admin/browse.jsp?JMSDestination=TestQueueOne
> Added : 
> I have tested with the 5.7.0 version of activemq and this bug doesn't exist. 

--
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] [Reopened] (AMQ-4571) Improve DestinationFilter to allow any filter to unsubscribe its wrapped destination from a durable subscruption

[Timothy Bish (JIRA)]

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

Timothy Bish reopened AMQ-4571:
---


Should account for nested filters too. 

> Improve DestinationFilter to allow any filter to unsubscribe its wrapped 
> destination from a durable subscruption
> 
>
> Key: AMQ-4571
> URL: https://issues.apache.org/jira/browse/AMQ-4571
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.9.0
>
>
> Related to AMQ-4356 lets make the durable unsbscribe possible from any 
> DestinationFilter so that custom filters can clean up properly. 

--
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-3621) Integrate Apache Shiro with ActiveMQ as "security solution"

[Les Hazlewood (JIRA)]

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

Les Hazlewood commented on AMQ-3621:


An update for those following this issue that might not be following the 
ActiveMQ dev mailing list:

I made quite a bit of progress over the weekend.  Here is the result of the 
latest effort:

https://github.com/lhazlewood/activemq/tree/trunk/activemq-shiro

Change log is here:

https://github.com/lhazlewood/activemq/commit/be2100ea2c5a421cd21a4c3ae158c65e6e14490f

It works as follows:

The ShiroPlugin installs 2 BrokerFilters at the moment:

- A SubjectFilter which is responsible for constructing and associating a 
Subject instance with Connections.  Downstream filters perform actual security 
checks.
- An AuthenticationFilter (downstream from the SubjectFilter) that enforces 
client authentication as necessary.  It supports system and anonymous 
connections as well if desired.

I still have to create an AuthorizationFilter (that would be downstream from 
the AuthenticationFilter) that would allow access control checks (can you 
subscribe to a destination or not, etc).

All of this code is tested with 100% class, method and line coverage.

Comments, suggestions and feedback are most welcome.

> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already 
> existing solution (Realm implementations) that are out there for Shiro.

--
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-4571) Improve DestinationFilter to allow any filter to unsubscribe its wrapped destination from a durable subscruption

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-4571.
---

Resolution: Fixed

Fixed on trunk

> Improve DestinationFilter to allow any filter to unsubscribe its wrapped 
> destination from a durable subscruption
> 
>
> Key: AMQ-4571
> URL: https://issues.apache.org/jira/browse/AMQ-4571
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.9.0
>
>
> Related to AMQ-4356 lets make the durable unsbscribe possible from any 
> DestinationFilter so that custom filters can clean up properly. 

--
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-4571) Improve DestinationFilter to allow any filter to unsubscribe its wrapped destination from a durable subscruption

[Timothy Bish (JIRA)]

Timothy Bish created AMQ-4571:
-

 Summary: Improve DestinationFilter to allow any filter to 
unsubscribe its wrapped destination from a durable subscruption
 Key: AMQ-4571
 URL: https://issues.apache.org/jira/browse/AMQ-4571
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 5.8.0
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Minor
 Fix For: 5.9.0


Related to AMQ-4356 lets make the durable unsbscribe possible from any 
DestinationFilter so that custom filters can clean up properly. 

--
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-4568) org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation hangs

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4568:
---

Added the timeout patch to trunk. 

> org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation 
> hangs
> --
>
> Key: AMQ-4568
> URL: https://issues.apache.org/jira/browse/AMQ-4568
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Priority: Minor
> Attachments: AMQ-4568.patch, testRawTransformation.txt
>
>
> This test is currently hanging.  I'll attach a stack trace and a test patch 
> which includes a 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-4570) PFC on durable topics without needing TX or Producer window.

[Edstrom Johan (JIRA)]

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

Edstrom Johan updated AMQ-4570:
---

Attachment: topic.patch

> PFC on durable topics without needing TX or Producer window.
> 
>
> Key: AMQ-4570
> URL: https://issues.apache.org/jira/browse/AMQ-4570
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.4.2
>Reporter: Edstrom Johan
>Priority: Minor
> Attachments: topic.patch
>
>
> Patch to provide a counter that keeps track of persistent messages enqueued 
> and dispatched to durable subscribers on a topic.
> This gives a more "accurate" producer flow control so that a topic
> will not flood the store memory.

--
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-4570) PFC on durable topics without needing TX or Producer window.

[Edstrom Johan (JIRA)]

Edstrom Johan created AMQ-4570:
--

 Summary: PFC on durable topics without needing TX or Producer 
window.
 Key: AMQ-4570
 URL: https://issues.apache.org/jira/browse/AMQ-4570
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.4.2
Reporter: Edstrom Johan
Priority: Minor


Patch to provide a counter that keeps track of persistent messages enqueued and 
dispatched to durable subscribers on a topic.
This gives a more "accurate" producer flow control so that a topic
will not flood the store memory.

--
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-4569) Stomp inactivity timeout takes significantly longer specified

[Karen Morrissey (JIRA)]

Karen Morrissey created AMQ-4569:


 Summary: Stomp inactivity timeout takes significantly longer 
specified
 Key: AMQ-4569
 URL: https://issues.apache.org/jira/browse/AMQ-4569
 Project: ActiveMQ
  Issue Type: Bug
  Components: stomp
Affects Versions: 5.8.0
 Environment: Windows 7, JRE 7.
Reporter: Karen Morrissey
Priority: Minor


When I specify a timeout using a connector like the following to get a 5-minute 
idle timeout
{code:xml}

{code}
It takes 15 minutes for it to time out. I tried one previously at 90 (15 
minutes), and it had not timed out after 35 minutes, when I had to leave.

So, it appears the timeout takes 3 times longer than specified. I find it 
suspicious that there is a call somewhere I saw in the code that divides the 
timeout period by 3.


--
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.NMS.ActiveMQ 1.6.0

[Hiram Chirino]

+1

On Mon, Jun 3, 2013 at 11:15 AM, Timothy Bish  wrote:
> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.0
>
> New in this release:
>
> * Adds support for non-blocking redelivery.
> * Supports priority backups for Failover transport.
> * Supports an Optimized Ack mode for MessageConsumers.
> * Adds Message Audits to prevent duplicate deliveries on Failover.
> * Implements the ISession Recover method.
> * Adds support for purging locally created temp destinations.
> * Properly handles cluster client re-balancing in Failover Transport.
> * Plus a lot more fixes and stability improvements.
>
> The binaries and source bundles for the Release Candidate can be found here:
> http://people.apache.org/~tabish/nms-1.6.0/
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v160.html
>
> The list of issues resolved is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&styleName=Html&version=12315987
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.0
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.fusesource.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
> www.camelone.org : The open source integration conference:
>



-- 
Hiram Chirino

Engineering | Red Hat, Inc.

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

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.6.0

[Christian Posta]

+1 (non binding i suppose?)


On Mon, Jun 3, 2013 at 11:22 PM, Claus Ibsen  wrote:

> +1
>
> On Mon, Jun 3, 2013 at 5:15 PM, Timothy Bish  wrote:
> > Hello
> >
> > This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.0
> >
> > New in this release:
> >
> > * Adds support for non-blocking redelivery.
> > * Supports priority backups for Failover transport.
> > * Supports an Optimized Ack mode for MessageConsumers.
> > * Adds Message Audits to prevent duplicate deliveries on Failover.
> > * Implements the ISession Recover method.
> > * Adds support for purging locally created temp destinations.
> > * Properly handles cluster client re-balancing in Failover Transport.
> > * Plus a lot more fixes and stability improvements.
> >
> > The binaries and source bundles for the Release Candidate can be found
> here:
> > http://people.apache.org/~tabish/nms-1.6.0/
> >
> > The Wiki Page for this release is here:
> > http://activemq.apache.org/nms/apachenmsactivemq-v160.html
> >
> > The list of issues resolved is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&styleName=Html&version=12315987
> >
> > Please cast your votes (the vote will be open for 72 hrs):
> >
> > [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > Here's my +1
> >
> > Regards
> >
> > --
> > Tim Bish
> > Sr Software Engineer | RedHat Inc.
> > tim.b...@redhat.com | www.fusesource.com | www.redhat.com
> > skype: tabish121 | twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> > www.camelone.org : The open source integration conference:
> >
>
>
>
> --
> Claus Ibsen
> -
> www.camelone.org: The open source integration conference.
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cib...@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>



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

[jira] [Updated] (AMQ-4568) org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation hangs

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-4568:
-

Attachment: testRawTransformation.txt

Stack trace on hung test

> org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation 
> hangs
> --
>
> Key: AMQ-4568
> URL: https://issues.apache.org/jira/browse/AMQ-4568
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Priority: Minor
> Attachments: AMQ-4568.patch, testRawTransformation.txt
>
>
> This test is currently hanging.  I'll attach a stack trace and a test patch 
> which includes a 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-4568) org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation hangs

[Kevin Earls (JIRA)]

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

Kevin Earls updated AMQ-4568:
-

Attachment: AMQ-4568.patch

Updated test with timeout added to prevent hangs

> org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation 
> hangs
> --
>
> Key: AMQ-4568
> URL: https://issues.apache.org/jira/browse/AMQ-4568
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>Priority: Minor
> Attachments: AMQ-4568.patch
>
>
> This test is currently hanging.  I'll attach a stack trace and a test patch 
> which includes a 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] [Created] (AMQ-4568) org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation hangs

[Kevin Earls (JIRA)]

Kevin Earls created AMQ-4568:


 Summary: 
org.apache.activemq.transport.amqp.AmqpTransformerTest#testRawTransformation 
hangs
 Key: AMQ-4568
 URL: https://issues.apache.org/jira/browse/AMQ-4568
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
Reporter: Kevin Earls
Priority: Minor
 Attachments: AMQ-4568.patch

This test is currently hanging.  I'll attach a stack trace and a test patch 
which includes a 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