[jira] [Updated] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

2013-09-19 Thread Timothy Bish (JIRA) 

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

Timothy Bish updated AMQ-4710:
--

Fix Version/s: 5.10.0

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Fix For: 5.10.0
>
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
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-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

2013-09-19 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-4710:
---

Not sure this fix is really the way to go, on a busy system we could be 
canceling and rescheduling the timer quite a bit which introduces more overhead 
than I think is good here.  Would need to look at it more.  Probably won't make 
it into a v5.9.0 release. 

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
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-4729) mKahaDB master slave needs lock when filtered adapter locks are created on the fly

2013-09-19 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-4729:
-

a workaround is described at: 
https://issues.apache.org/jira/browse/AMQ-4365?focusedCommentId=13758262&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13758262

> mKahaDB master slave needs lock when filtered adapter locks are created on 
> the fly
> --
>
> Key: AMQ-4729
> URL: https://issues.apache.org/jira/browse/AMQ-4729
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.9.0
>
>
> {code}
>
>   
>   
> 
>   
> 
>   
> {code}
> problem:
> 1. Starting the slave with an "empty" database, i.e no queues results in the 
> slave trying to start and ultimately failing as the address is in use. 
> There's now lock. Pushing a message to TEST.FOO and then starting the 
> database works OK. The slave comes up and locks and waits.
> 2. Now, adding a TEST.FOO1 to the master. The master now has the two queues, 
> TEST.FOO and TEST.FOO1. Kill the master and let the slave take over. The 
> slave only sees TEST.FOO. Not TEST.FOO1.

--
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-4729) mKahaDB master slave needs lock when filtered adapter locks are created on the fly

2013-09-19 Thread Gary Tully (JIRA) 

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

Gary Tully resolved AMQ-4729.
-

Resolution: Fixed

fix in http://git-wip-us.apache.org/repos/asf/activemq/commit/0f90695d

mKahaDB now has a lock (shared file by default) and suppresses the locks of 
filtered adapters

> mKahaDB master slave needs lock when filtered adapter locks are created on 
> the fly
> --
>
> Key: AMQ-4729
> URL: https://issues.apache.org/jira/browse/AMQ-4729
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.9.0
>
>
> {code}
>
>   
>   
> 
>   
> 
>   
> {code}
> problem:
> 1. Starting the slave with an "empty" database, i.e no queues results in the 
> slave trying to start and ultimately failing as the address is in use. 
> There's now lock. Pushing a message to TEST.FOO and then starting the 
> database works OK. The slave comes up and locks and waits.
> 2. Now, adding a TEST.FOO1 to the master. The master now has the two queues, 
> TEST.FOO and TEST.FOO1. Kill the master and let the slave take over. The 
> slave only sees TEST.FOO. Not TEST.FOO1.

--
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-4729) mKahaDB master slave needs lock when filtered adapter locks are created on the fly

2013-09-19 Thread Gary Tully (JIRA) 
Gary Tully created AMQ-4729:
---

 Summary: mKahaDB master slave needs lock when filtered adapter 
locks are created on the fly
 Key: AMQ-4729
 URL: https://issues.apache.org/jira/browse/AMQ-4729
 Project: ActiveMQ
  Issue Type: Bug
  Components: Message Store
Affects Versions: 5.8.0
Reporter: Gary Tully
Assignee: Gary Tully
 Fix For: 5.9.0


{code}
   
  
  

  

  
{code}
problem:

1. Starting the slave with an "empty" database, i.e no queues results in the 
slave trying to start and ultimately failing as the address is in use. There's 
now lock. Pushing a message to TEST.FOO and then starting the database works 
OK. The slave comes up and locks and waits.

2. Now, adding a TEST.FOO1 to the master. The master now has the two queues, 
TEST.FOO and TEST.FOO1. Kill the master and let the slave take over. The slave 
only sees TEST.FOO. Not TEST.FOO1.

--
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-4728) Develop a pluggable locker that can be shared broker-wide for both the persistence adapter as well as the redelivery plugin

2013-09-19 Thread Paul Gale (JIRA) 
Paul Gale created AMQ-4728:
--

 Summary: Develop a pluggable locker that can be shared broker-wide 
for both the persistence adapter as well as the redelivery plugin
 Key: AMQ-4728
 URL: https://issues.apache.org/jira/browse/AMQ-4728
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker, Message Store
Affects Versions: 5.8.0
Reporter: Paul Gale
 Fix For: 5.9.0


Modify the redelivery plugin so that it can be configured with a pluggable 
storage locker.

Allow the same locker to optionally be configured at the broker level so that 
the same locker instance can be shared by all components that need it, e.g., 
the persistence adapter (including multi kaha) and the redelivery plugin.

--
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-4426) Allow XAPooledConnectionFactory to be used from ee ( implement ObjectFactory, [Queue|Topic]ConnectionFactory

2013-09-19 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-4426:
-

https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=c3875222 is 
also relevant to ensure we don't default to a local tx or autoack after an abort

> Allow XAPooledConnectionFactory to be used from ee ( implement ObjectFactory, 
> [Queue|Topic]ConnectionFactory
> 
>
> Key: AMQ-4426
> URL: https://issues.apache.org/jira/browse/AMQ-4426
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: activemq-pool
>Affects Versions: 5.8.0
> Environment: ee container eg: jboss
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: connectionfactory, ee, jboss, jta, pool, xa
> Fix For: 5.9.0
>
>
> To easily bind a connection factory that is aware of the containers 
> transaction manager(tm) the use of javax.naming ObjectFactory comes in handy.
> This allows the connection factory to create instances from a jndi lookup.
> Having the tm resolved from jndi at runtime makes sense to avoid wiring 
> dependencies.
> Having the XAPooledConnectionFactory implement the ee type Queue and Topic 
> connection factory interfaces makes such a factory useable.

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

[RESULT][VOTE] Release ActiveMQ-CPP v3.8.1

2013-09-19 Thread Timothy Bish 

Results of the ActiveMQ-CPP v3.8.1 vote:

Vote passes with 6 binding +1 votes.

The following binding votes were received:

Gary Tully
Claus Ibsen
Timothy Bish
Hiram Chirino
Christian Posta
Dejan Bosanac

I'll start pushing out the release bundles and update the Wiki.

--
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/

[jira] [Commented] (AMQ-2453) start/control-script is not suitable for professional environments

2013-09-19 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-2453:
---

In order to gain edit access you should create an account on the confluence 
Wiki and then send an email to the dev forum requesting karma to edit.  Your 
account should be linked to the same email that's associated with your ICLA so 
we can match them up.  

> start/control-script is not suitable for professional environments
> --
>
> Key: AMQ-2453
> URL: https://issues.apache.org/jira/browse/AMQ-2453
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.0
>Reporter: Marc Schöchlin
>Assignee: Timothy Bish
> Fix For: NEEDS_REVIEWED
>
> Attachments: activemq, usage-example.txt
>
>
> The start-scripts "activemq" and "activemq-admin" do not seem to be ready for 
> production use.
> Reasons:
> - Server does not run in background
>   => this can be done by redirecting output to a file and run in background
>   => in my opinion this should be implemented directly in java
>   => the console log should be written by log4j to 
> /data/console.log
> - The process should be started on a non-root user 
>   => use 'su -c "$COMMAND" - $RUN_AS_USER' 
>   => this should be defined in /etc/activemq.conf
> - The script should support a "reload" feature to reload the configurartion
>   (if activemq supports reloading)
> - The script should support a "status" option
>   => this should show a quick overview about the state of activemq
>   => this should return a value != 0 if the service is not working
>  (this is important for cluster integration)
> Does anybody already working on these items?
> Do you have suggestions for a implementation?

--
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-4594) Replace web console with hawtio

2013-09-19 Thread Dejan Bosanac (JIRA) 

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

Dejan Bosanac commented on AMQ-4594:


Added log plugin for hawtio, so we can inspect and search logs in the console.

There's an ugly message on standard console when starting broker, tied to


https://github.com/jboss-fuse/fuse/issues/95

We should get this fixed before the release.

> Replace web console with hawtio
> ---
>
> Key: AMQ-4594
> URL: https://issues.apache.org/jira/browse/AMQ-4594
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.8.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.9.0
>
>
> Our administration web console has come to age and we should replace with 
> hawtio (http://hawt.io) project. Of course, we should make sure that ActiveMQ 
> plugin is feature compatible with current console.
> hawtio provides lots of extra capabilities over the old web console; we can 
> send messages, move messages, delete messages and easily replay DLQ messages; 
> together with visualising producer/consumer flows and providing real time 
> metrics and charting on destinations. Plus hawtio is much smaller than the 
> old web console; we can also use the hawtio console remotely to connect to 
> other brokers and JVMs which just contain the tiny jolokia java agent

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

2013-09-19 Thread Wieslaw Dudek (JIRA) 

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

Wieslaw Dudek commented on AMQ-4533:


Thank you for your comment!
We do not care about the long-sleeping message but about all the prefetched 
messages for the sleeping consumer which needs to be redispatched & delivered 
to other consumers. This is all what needs to be guaranteed here no matter what 
option we are going to use in the spring listener we do not want the “freeze” - 
meaning that all pending/prefetched messages have to be re-dispatched from such 
“slow” /or frozen/ consumers to other ones. However I am still concerned about 
the ignoreIdleConsumers="false" and abortConnection="true" which is going to 
work for me. Why ignoreIdleConsumers="false" helps so much when you said it 
should not? Could it be checked as we would like to avoid this?

> 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
>Assignee: Timothy Bish
> Fix For: 5.9.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, 
> AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, 
> AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, 
> AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, 
> AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, 
> AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
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-4713) org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages fails

2013-09-19 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-4713.
---

Resolution: Fixed
  Assignee: Timothy Bish  (was: Jean-Baptiste Onofré)

Patch applied, tests passing now.  Thanks!

> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages
>  fails
> -
>
> Key: AMQ-4713
> URL: https://issues.apache.org/jira/browse/AMQ-4713
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: mac os x, jdk7
>Reporter: Kevin Earls
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.9.0
>
> Attachments: AMQ-4713.patch
>
>
> This fails intermittently with one of the two errors shown below:
> Running org.apache.activemq.transport.amqp.JMSClientTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.778 sec 
> <<< FAILURE!
> testTXConsumerAndLargeNumberOfMessages(org.apache.activemq.transport.amqp.JMSClientTest)
>   Time elapsed: 2.027 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<15>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages(JMSClientTest.java:193)
> Results :
> Failed tests: 
>   JMSClientTest.testTXConsumerAndLargeNumberOfMessages:193 expected:<0> but 
> was:<15>
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0
> ---
>  T E S T S
> ---
> Running org.apache.activemq.transport.amqp.JMSClientTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 40.032 sec 
> <<< FAILURE!
> testTXConsumerAndLargeNumberOfMessages(org.apache.activemq.transport.amqp.JMSClientTest)
>   Time elapsed: 18.031 sec  <<< FAILURE!
> java.lang.AssertionError: Should receive message: 159
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertNotNull(Assert.java:621)
>   at 
> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages(JMSClientTest.java:181)

--
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] [Closed] (AMQNET-442) Clients with cultures where decimalpoint separator is other than "." fails to connect because version no is parsed as float/Single

2013-09-19 Thread Timothy Bish (JIRA) 

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

Timothy Bish closed AMQNET-442.
---

   Resolution: Duplicate
Fix Version/s: 1.6.0

> Clients with cultures where decimalpoint separator is other than "." fails to 
> connect because version no is parsed as float/Single
> --
>
> Key: AMQNET-442
> URL: https://issues.apache.org/jira/browse/AMQNET-442
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.5.3
>Reporter: Roy Müller
>Assignee: Jim Gomes
> Fix For: 1.6.0
>
>
> Client connecting with STOMP fails with System.FormatException: Input string 
> was not in a correct format. This happens on computers with a culture that 
> has eg. "," as decimal separator instead of ".".
> DEBUG: Exception received in the Inactivity Monitor: System.FormatException: 
> Input string was not in a correct format.
>at System.Number.ParseSingle(String value, NumberStyles options, 
> NumberFormatInfo numfmt)
>at System.Single.Parse(String s)
>at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame 
> frame) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 199
>at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame 
> frame) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 153
>at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader 
> dataIn) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 123
>at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in 
> c:\dev\NMS.Stomp\src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285

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

Jenkins build is back to normal : ActiveMQ-Trunk-Deploy » ActiveMQ :: Client #850

2013-09-19 Thread Apache Jenkins Server 
See

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

2013-09-19 Thread Apache Jenkins Server 
See

[jira] [Commented] (AMQNET-442) Clients with cultures where decimalpoint separator is other than "." fails to connect because version no is parsed as float/Single

2013-09-19 Thread JIRA 

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

Roy Müller commented on AMQNET-442:
---

Fix in class StompWireFormat.cs method ReadConnected (line 201) is to specify a 
formatter:

remoteWireFormatInfo.Version = Single.Parse(frame.RemoveProperty("version"), 
new NumberFormatInfo{NumberDecimalSeparator = "."});

> Clients with cultures where decimalpoint separator is other than "." fails to 
> connect because version no is parsed as float/Single
> --
>
> Key: AMQNET-442
> URL: https://issues.apache.org/jira/browse/AMQNET-442
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.5.3
>Reporter: Roy Müller
>Assignee: Jim Gomes
>
> Client connecting with STOMP fails with System.FormatException: Input string 
> was not in a correct format. This happens on computers with a culture that 
> has eg. "," as decimal separator instead of ".".
> DEBUG: Exception received in the Inactivity Monitor: System.FormatException: 
> Input string was not in a correct format.
>at System.Number.ParseSingle(String value, NumberStyles options, 
> NumberFormatInfo numfmt)
>at System.Single.Parse(String s)
>at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame 
> frame) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 199
>at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame 
> frame) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 153
>at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader 
> dataIn) in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 
> 123
>at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in 
> c:\dev\NMS.Stomp\src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285

--
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] (AMQNET-442) Clients with cultures where decimalpoint separator is other than "." fails to connect because version no is parsed as float/Single

2013-09-19 Thread JIRA 
Roy Müller created AMQNET-442:
-

 Summary: Clients with cultures where decimalpoint separator is 
other than "." fails to connect because version no is parsed as float/Single
 Key: AMQNET-442
 URL: https://issues.apache.org/jira/browse/AMQNET-442
 Project: ActiveMQ .Net
  Issue Type: Bug
  Components: Stomp
Affects Versions: 1.5.3
Reporter: Roy Müller
Assignee: Jim Gomes


Client connecting with STOMP fails with System.FormatException: Input string 
was not in a correct format. This happens on computers with a culture that has 
eg. "," as decimal separator instead of ".".

DEBUG: Exception received in the Inactivity Monitor: System.FormatException: 
Input string was not in a correct format.
   at System.Number.ParseSingle(String value, NumberStyles options, 
NumberFormatInfo numfmt)
   at System.Single.Parse(String s)
   at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadConnected(StompFrame frame) 
in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 199
   at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame frame) 
in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 153
   at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn) 
in c:\dev\NMS.Stomp\src\main\csharp\Protocol\StompWireFormat.cs:line 123
   at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop() in 
c:\dev\NMS.Stomp\src\main\csharp\Transport\Tcp\TcpTransport.cs:line 285

--
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-4594) Replace web console with hawtio

2013-09-19 Thread Dejan Bosanac (JIRA) 

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

Dejan Bosanac commented on AMQ-4594:


Yeah, but that build is older than my fix. For some reason snapshots are not 
being built lately. I just started one, let's see if we'll have a new snapshot 
soon.

> Replace web console with hawtio
> ---
>
> Key: AMQ-4594
> URL: https://issues.apache.org/jira/browse/AMQ-4594
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.8.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.9.0
>
>
> Our administration web console has come to age and we should replace with 
> hawtio (http://hawt.io) project. Of course, we should make sure that ActiveMQ 
> plugin is feature compatible with current console.
> hawtio provides lots of extra capabilities over the old web console; we can 
> send messages, move messages, delete messages and easily replay DLQ messages; 
> together with visualising producer/consumer flows and providing real time 
> metrics and charting on destinations. Plus hawtio is much smaller than the 
> old web console; we can also use the hawtio console remotely to connect to 
> other brokers and JVMs which just contain the tiny jolokia java agent

--
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-4713) org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages fails

2013-09-19 Thread Kevin Earls (JIRA) 

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

Kevin Earls updated AMQ-4713:
-

Attachment: AMQ-4713.patch

As discussed in earlier email, the problem here is the way we were using 
delivery tags.  


> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages
>  fails
> -
>
> Key: AMQ-4713
> URL: https://issues.apache.org/jira/browse/AMQ-4713
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: mac os x, jdk7
>Reporter: Kevin Earls
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 5.9.0
>
> Attachments: AMQ-4713.patch
>
>
> This fails intermittently with one of the two errors shown below:
> Running org.apache.activemq.transport.amqp.JMSClientTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.778 sec 
> <<< FAILURE!
> testTXConsumerAndLargeNumberOfMessages(org.apache.activemq.transport.amqp.JMSClientTest)
>   Time elapsed: 2.027 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<15>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages(JMSClientTest.java:193)
> Results :
> Failed tests: 
>   JMSClientTest.testTXConsumerAndLargeNumberOfMessages:193 expected:<0> but 
> was:<15>
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0
> ---
>  T E S T S
> ---
> Running org.apache.activemq.transport.amqp.JMSClientTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 40.032 sec 
> <<< FAILURE!
> testTXConsumerAndLargeNumberOfMessages(org.apache.activemq.transport.amqp.JMSClientTest)
>   Time elapsed: 18.031 sec  <<< FAILURE!
> java.lang.AssertionError: Should receive message: 159
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertNotNull(Assert.java:621)
>   at 
> org.apache.activemq.transport.amqp.JMSClientTest.testTXConsumerAndLargeNumberOfMessages(JMSClientTest.java:181)

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

2013-09-19 Thread Dejan Bosanac (JIRA) 

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

Dejan Bosanac commented on AMQ-4533:


The problem is how the spring message listener works. It doesn't use message 
listener like you would in a JMS app. Instead it does receive() on the session, 
gets the message and manually executes onMessage() on the listener. In auto 
acknowledge mode as soon as receive() is done, the message is acked and 
considered processed. So the message that sleeps forever will not be resent to 
other consumers when this consumer is detected slow. Turning to client 
acknowlement Spring actually manually acks the message when onMessage() 
completes. So when we close the consumer, the current long-sleeping message 
will be replayed to other consumers.

> 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
>Assignee: Timothy Bish
> Fix For: 5.9.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, 
> AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, 
> AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, 
> AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, 
> AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, 
> AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
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-2453) start/control-script is not suitable for professional environments

2013-09-19 Thread JIRA 

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

Marc Schöchlin commented on AMQ-2453:
-

I submitted the ICLA and get the confirmation the the ICLA is filed.

If necessary and useful, i can provide documentation for wiki regarding the 
init-script and fixes for the init script :-)



> start/control-script is not suitable for professional environments
> --
>
> Key: AMQ-2453
> URL: https://issues.apache.org/jira/browse/AMQ-2453
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.0
>Reporter: Marc Schöchlin
>Assignee: Timothy Bish
> Fix For: NEEDS_REVIEWED
>
> Attachments: activemq, usage-example.txt
>
>
> The start-scripts "activemq" and "activemq-admin" do not seem to be ready for 
> production use.
> Reasons:
> - Server does not run in background
>   => this can be done by redirecting output to a file and run in background
>   => in my opinion this should be implemented directly in java
>   => the console log should be written by log4j to 
> /data/console.log
> - The process should be started on a non-root user 
>   => use 'su -c "$COMMAND" - $RUN_AS_USER' 
>   => this should be defined in /etc/activemq.conf
> - The script should support a "reload" feature to reload the configurartion
>   (if activemq supports reloading)
> - The script should support a "status" option
>   => this should show a quick overview about the state of activemq
>   => this should return a value != 0 if the service is not working
>  (this is important for cluster integration)
> Does anybody already working on these items?
> Do you have suggestions for a implementation?

--
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-4594) Replace web console with hawtio

2013-09-19 Thread Miquel Angel Escolar (JIRA) 

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

Miquel Angel Escolar commented on AMQ-4594:
---

It seems to be a repackaging problem, because if i remove manually all excluded 
libs in assembly it works.

> Replace web console with hawtio
> ---
>
> Key: AMQ-4594
> URL: https://issues.apache.org/jira/browse/AMQ-4594
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.8.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.9.0
>
>
> Our administration web console has come to age and we should replace with 
> hawtio (http://hawt.io) project. Of course, we should make sure that ActiveMQ 
> plugin is feature compatible with current console.
> hawtio provides lots of extra capabilities over the old web console; we can 
> send messages, move messages, delete messages and easily replay DLQ messages; 
> together with visualising producer/consumer flows and providing real time 
> metrics and charting on destinations. Plus hawtio is much smaller than the 
> old web console; we can also use the hawtio console remotely to connect to 
> other brokers and JVMs which just contain the tiny jolokia java agent

--
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