Jenkins build is back to stable : ActiveMQ-Java7 » ActiveMQ :: Web #144
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-web/144/
Jenkins build is still unstable: ActiveMQ-Java7 » ActiveMQ :: HTTP Protocol Support #144
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-http/144/
Jenkins build is back to stable : ActiveMQ-Java7 » ActiveMQ :: RA #144
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-ra/144/
Jenkins build is still unstable: ActiveMQ-Java7 #144
See https://builds.apache.org/job/ActiveMQ-Java7/changes
Re: what is the alternate for KahaPersistenceAdapter in 5.8
On 02/20/2013 02:04 AM, Ravindra wrote:
Hi,
Thanks for Given response.
My next question is that how we can change class name in Master.xml from
KahaPersistenceAdapter to KahaDBPersistenceAdapter. it not allowing to
change value to KahaDBPersistenceAdapter.
example
amq:persistenceAdapter
amq:kahaPersistenceAdapter
directory=${activemq.broker.datadir}
/
/amq:persistenceAdapter
XSD is not supporting KahaDBPersistenceAdapter.
persistenceAdapter
kahaDB directory=${activemq.data}/kahadb/
/persistenceAdapter
so XSD in not changed according to new KahaDBPersistenceAdapter value in
5.8?
Or we have any other way to change this value.
Thanks,
Ravindra
--
View this message in context:
http://activemq.2283324.n4.nabble.com/what-is-the-alternate-for-KahaPersistenceAdapter-in-5-8-tp4663685p4663764.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
--
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/
Re: ConnectionFailedException with ActiveMQ 5.6, Camel2.10, JBoss5.1
We have a single Broker URL. There are no secondary brokers which we can try if the primary fails. And also i wanted to understand will it help if i Use like below : bean id=amqConnectionFactory class=org.apache.activemq.ActiveMQConnectionFactory property name=brokerURL valuefailover:(tcp://localhost:61616)/value /property property name=transportListener bean class=org.test.common.TransportListener / /property /bean -- View this message in context: http://activemq.2283324.n4.nabble.com/ConnectionFailedException-with-ActiveMQ-5-6-Camel2-10-JBoss5-1-tp4663755p4663773.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: what is the alternate for KahaPersistenceAdapter in 5.8
Hi,
persistenceAdapter
kahaDB directory=${activemq.data}/kahadb/
/persistenceAdapter
This is not working.
Having any other way to use KahaDBPersistenceAdapter ?
Thanks,
Ravi
--
View this message in context:
http://activemq.2283324.n4.nabble.com/what-is-the-alternate-for-KahaPersistenceAdapter-in-5-8-tp4663685p4663776.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Closed] (AMQCPP-464) Deadlock during normal task termination
[ https://issues.apache.org/jira/browse/AMQCPP-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Weaver closed AMQCPP-464. --- Termination hangs no longer recreatable with latest SNAPSHOT. Deadlock during normal task termination --- Key: AMQCPP-464 URL: https://issues.apache.org/jira/browse/AMQCPP-464 Project: ActiveMQ C++ Client Issue Type: Bug Components: Decaf Affects Versions: 3.6.0 Environment: Windows XP VS2005 Reporter: Scott Weaver Assignee: Timothy Bish Priority: Critical Fix For: 3.6.0 Attachments: CrashHang_Report__CMStressD.exe__02182013132527878.mht, CrashHang_Report__CMStressD.exe__02192013112259191.mht Normal task termination hangs occasionally. -- 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] (AMQCPP-464) Deadlock during normal task termination
[ https://issues.apache.org/jira/browse/AMQCPP-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Weaver resolved AMQCPP-464. - Resolution: Fixed Fix Version/s: 3.6.0 Resolved with latest 3.6.x SNAPSHOT - 12 hour regression test - No access violations and no hangs! Deadlock during normal task termination --- Key: AMQCPP-464 URL: https://issues.apache.org/jira/browse/AMQCPP-464 Project: ActiveMQ C++ Client Issue Type: Bug Components: Decaf Affects Versions: 3.6.0 Environment: Windows XP VS2005 Reporter: Scott Weaver Assignee: Timothy Bish Priority: Critical Fix For: 3.6.0 Attachments: CrashHang_Report__CMStressD.exe__02182013132527878.mht, CrashHang_Report__CMStressD.exe__02192013112259191.mht Normal task termination hangs occasionally. -- 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: what is the alternate for KahaPersistenceAdapter in 5.8
On 02/20/2013 08:13 AM, Ravindra wrote:
Hi,
persistenceAdapter
kahaDB directory=${activemq.data}/kahadb/
/persistenceAdapter
This is not working.
Having any other way to use KahaDBPersistenceAdapter ?
Thanks,
Ravi
Did you include the activemq-kahadb-store dependency in your project?
You need to provide some more details of your configuration, errors etc.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/what-is-the-alternate-for-KahaPersistenceAdapter-in-5-8-tp4663685p4663776.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
--
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-4122) Lease Database Locker failover broken
[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582204#comment-13582204 ] st.h commented on AMQ-4122: --- I did some first tests with the 5.8 Release version. The lease database locker seems to work as expected now. However, it seems that it is always the last node that is available that becomes master. For instance: start node1 - node1 is master start node2 - node1 gives up being master; node2 becomes master stop node1 - node2 stays master start node1 - node2 gives up being master; node1 becomes master While I am not sure if this is the intended behavior, right now I do not expect any issues with that. Lease Database Locker failover broken - Key: AMQ-4122 URL: https://issues.apache.org/jira/browse/AMQ-4122 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Environment: Java 7u9, SUSE 11, Mysql Reporter: st.h Assignee: Gary Tully Fix For: 5.8.0 Attachments: activemq-kyle.xml, activemq.xml, activemq.xml We are using ActiveMQ 5.7.0 together with a mysql database and could not observe correct failover behavior with lease database locker. It seems that there is a race condition, which prevents the correct failover procedure. We noticed that when starting up two instances, both instance are becoming master. We did several test, including the following and could not observe intended functionality: - shutdown all instances - manipulate database lock that one node has lock and set expiry time in distance future - start up both instances. both instances are unable to acquire lock, as the lock hasn't expired, which should be correct behavior. - update the expiry time in database, so that the lock is expired. - first instance notices expired lock and becomes master - when second instance checks for lock, it also updates the database and becomes master. To my understanding the second instance should not be able to update the lock, as it is held by the first instance and should not be able to become master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4336) Connection reset exception occurred on Bulk msg producer
Tamilmaran created AMQ-4336:
---
Summary: Connection reset exception occurred on Bulk msg producer
Key: AMQ-4336
URL: https://issues.apache.org/jira/browse/AMQ-4336
Project: ActiveMQ
Issue Type: Bug
Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
I have a Bulk MSG producer which sends 1000 messages for every 4 seconds.
But after an hour, Connection reset exception occurred for Bulk MSG producer:-
2013-02-18 21:45:45,149 | WARN | Transport Connection to:
tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset |
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport:
ssl:///10.2.44.73:59355
10.2.44.73-Bulk MSG producer IP
ActiveMQ is using File based cursor and producer control.
ActiveMQ configuration:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd;
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.conf}/credentials.properties/value
/property
/bean
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.data}
offlineDurableSubscriberTimeout=2160
offlineDurableSubscriberTaskSchedule=180
destinationPolicy
policyMap
policyEntries
policyEntry topic=gt; producerFlowControl=false
memoryLimit=900mb
pendingSubscriberPolicy
vmCursor/
/pendingSubscriberPolicy
pendingDurableSubscriberPolicy
fileDurableSubscriberCursor/
/pendingDurableSubscriberPolicy
/policyEntry
policyEntry queue=gt; producerFlowControl=false
memoryLimit=20mb
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext createConnector=false/
/managementContext
persistenceAdapter
kahaDB ignoreMissingJournalfiles=true
directory=${activemq.data}/kahadb/
/persistenceAdapter
systemUsage
systemUsage sendFailIfNoSpaceAfterTimeout=15000
memoryUsage
memoryUsage limit=900 mb/
/memoryUsage
storeUsage
storeUsage limit=100 gb/
/storeUsage
tempUsage
tempUsage limit=50 gb/
/tempUsage
/systemUsage
/systemUsage
sslContext
sslContext keyStore=file:${activemq.conf}\broker.ks
keyStorePassword=HVObfvBd@zDo trustStore=file:${activemq.conf}\client.ks
trustStorePassword=HVObfvBd@zDo/
/sslContext
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:61616/
transportConnector name=ssl uri=ssl://0.0.0.0:61617/
transportConnector name=stomp uri=stomp://0.0.0.0:61613/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:61614/
/transportConnectors
/broker
import resource=jetty.xml/
/beans
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4336) Connection reset exception occurred on Bulk msg producer
[
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamilmaran updated AMQ-4336:
Attachment: activemq.xml
Connection reset exception occurred on Bulk msg producer
Key: AMQ-4336
URL: https://issues.apache.org/jira/browse/AMQ-4336
Project: ActiveMQ
Issue Type: Bug
Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Attachments: activemq.xml
I have a Bulk MSG producer which sends 1000 messages for every 4 seconds.
But after an hour, Connection reset exception occurred for Bulk MSG producer:-
2013-02-18 21:45:45,149 | WARN | Transport Connection to:
tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset |
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
Transport: ssl:///10.2.44.73:59355
10.2.44.73-Bulk MSG producer IP
ActiveMQ is using File based cursor and producer control.
ActiveMQ configuration:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd;
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.conf}/credentials.properties/value
/property
/bean
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.data}
offlineDurableSubscriberTimeout=2160
offlineDurableSubscriberTaskSchedule=180
destinationPolicy
policyMap
policyEntries
policyEntry topic=gt; producerFlowControl=false
memoryLimit=900mb
pendingSubscriberPolicy
vmCursor/
/pendingSubscriberPolicy
pendingDurableSubscriberPolicy
fileDurableSubscriberCursor/
/pendingDurableSubscriberPolicy
/policyEntry
policyEntry queue=gt; producerFlowControl=false
memoryLimit=20mb
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext createConnector=false/
/managementContext
persistenceAdapter
kahaDB ignoreMissingJournalfiles=true
directory=${activemq.data}/kahadb/
/persistenceAdapter
systemUsage
systemUsage sendFailIfNoSpaceAfterTimeout=15000
memoryUsage
memoryUsage limit=900 mb/
/memoryUsage
storeUsage
storeUsage limit=100 gb/
/storeUsage
tempUsage
tempUsage limit=50 gb/
/tempUsage
/systemUsage
/systemUsage
sslContext
sslContext keyStore=file:${activemq.conf}\broker.ks
keyStorePassword=HVObfvBd@zDo trustStore=file:${activemq.conf}\client.ks
trustStorePassword=HVObfvBd@zDo/
/sslContext
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:61616/
transportConnector name=ssl uri=ssl://0.0.0.0:61617/
transportConnector name=stomp uri=stomp://0.0.0.0:61613/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:61614/
/transportConnectors
/broker
import resource=jetty.xml/
/beans
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4336) Connection reset exception occurred on Bulk msg producer
[
https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamilmaran updated AMQ-4336:
Description:
I have a Bulk MSG producer which sends 1000 messages for every 4 seconds.
But after an hour, Connection reset exception occurred for Bulk MSG producer:-
2013-02-18 21:45:45,149 | WARN | Transport Connection to:
tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset |
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport:
ssl:///10.2.44.73:59355
10.2.44.73-Bulk MSG producer IP
ActiveMQ is using File based cursor and producer control.
was:
I have a Bulk MSG producer which sends 1000 messages for every 4 seconds.
But after an hour, Connection reset exception occurred for Bulk MSG producer:-
2013-02-18 21:45:45,149 | WARN | Transport Connection to:
tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset |
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport:
ssl:///10.2.44.73:59355
10.2.44.73-Bulk MSG producer IP
ActiveMQ is using File based cursor and producer control.
ActiveMQ configuration:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd;
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.conf}/credentials.properties/value
/property
/bean
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.data}
offlineDurableSubscriberTimeout=2160
offlineDurableSubscriberTaskSchedule=180
destinationPolicy
policyMap
policyEntries
policyEntry topic=gt; producerFlowControl=false
memoryLimit=900mb
pendingSubscriberPolicy
vmCursor/
/pendingSubscriberPolicy
pendingDurableSubscriberPolicy
fileDurableSubscriberCursor/
/pendingDurableSubscriberPolicy
/policyEntry
policyEntry queue=gt; producerFlowControl=false
memoryLimit=20mb
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext createConnector=false/
/managementContext
persistenceAdapter
kahaDB ignoreMissingJournalfiles=true
directory=${activemq.data}/kahadb/
/persistenceAdapter
systemUsage
systemUsage sendFailIfNoSpaceAfterTimeout=15000
memoryUsage
memoryUsage limit=900 mb/
/memoryUsage
storeUsage
storeUsage limit=100 gb/
/storeUsage
tempUsage
tempUsage limit=50 gb/
/tempUsage
/systemUsage
/systemUsage
sslContext
sslContext keyStore=file:${activemq.conf}\broker.ks
keyStorePassword=HVObfvBd@zDo trustStore=file:${activemq.conf}\client.ks
trustStorePassword=HVObfvBd@zDo/
/sslContext
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:61616/
transportConnector name=ssl uri=ssl://0.0.0.0:61617/
transportConnector name=stomp uri=stomp://0.0.0.0:61613/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:61614/
/transportConnectors
/broker
import resource=jetty.xml/
/beans
Connection reset exception occurred on Bulk msg producer
Key: AMQ-4336
URL: https://issues.apache.org/jira/browse/AMQ-4336
Project: ActiveMQ
Issue Type: Bug
Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Attachments: activemq.xml
I have a Bulk MSG producer which sends 1000 messages for every 4 seconds.
But after an hour, Connection reset exception occurred for Bulk MSG producer:-
2013-02-18 21:45:45,149 | WARN | Transport Connection to:
tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset |
org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
Transport: ssl:///10.2.44.73:59355
10.2.44.73-Bulk MSG producer IP
ActiveMQ is using File based cursor and producer control.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For
[jira] [Updated] (AMQ-4336) Connection reset exception occurred on Bulk msg producer
[ https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamilmaran updated AMQ-4336: Description: I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73-Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Attached activeMQ config was: I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73-Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Connection reset exception occurred on Bulk msg producer Key: AMQ-4336 URL: https://issues.apache.org/jira/browse/AMQ-4336 Project: ActiveMQ Issue Type: Bug Environment: ActiveMQ 5.6,NMS,C# Reporter: Tamilmaran Attachments: activemq.xml I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73-Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Attached activeMQ config -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4336) Connection reset exception occurred on Bulk msg producer
[ https://issues.apache.org/jira/browse/AMQ-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamilmaran updated AMQ-4336: Description: I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73- Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Attached activeMQ config was: I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73-Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Attached activeMQ config Connection reset exception occurred on Bulk msg producer Key: AMQ-4336 URL: https://issues.apache.org/jira/browse/AMQ-4336 Project: ActiveMQ Issue Type: Bug Environment: ActiveMQ 5.6,NMS,C# Reporter: Tamilmaran Attachments: activemq.xml I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. But after an hour, Connection reset exception occurred for Bulk MSG producer:- 2013-02-18 21:45:45,149 | WARN | Transport Connection to: tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///10.2.44.73:59355 10.2.44.73- Bulk MSG producer IP ActiveMQ is using File based cursor and producer control. Attached activeMQ config -- 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-4337) Messages with AMQ_SCHEDULED_DELAY do not respect transactions
Remo Gloor created AMQ-4337:
---
Summary: Messages with AMQ_SCHEDULED_DELAY do not respect
transactions
Key: AMQ-4337
URL: https://issues.apache.org/jira/browse/AMQ-4337
Project: ActiveMQ
Issue Type: Improvement
Reporter: Remo Gloor
Currently delayed messages are delivered even if the session it was sent in is
rolled back. According to
http://activemq.2283324.n4.nabble.com/AMQ-SCHEDULED-DELAY-and-transactional-boundaries-td4658339.html
this is because the message can be delivered far in the future and the
transaction would take to long.
I don't agree with that argument. The transaction can be short living. It is
only the enqueuing of the delayed message in the broker that has to be part of
the transaction. The delivery to the consumer is not part of the transaction
anymore.
e.g. consider the scenario in the following preudo code:
while (application_runs)
try{
msg = session.Receive();
session.SendDelayed(anotherMessage);
if (random(5) != 0) throw exception;
session.Commit();
} catch { session.Rollback; }
Currently a delayed message is sent for each retry. So we will get a lot more
messages in the future as we would expect. When delayed messages would respect
transactions just the successful ones would be enqueued. The other ones are
rolledback with the transaction.
--
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-4337) Messages with AMQ_SCHEDULED_DELAY do not respect transactions
[
https://issues.apache.org/jira/browse/AMQ-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQ-4337:
--
Priority: Minor (was: Major)
Messages with AMQ_SCHEDULED_DELAY do not respect transactions
-
Key: AMQ-4337
URL: https://issues.apache.org/jira/browse/AMQ-4337
Project: ActiveMQ
Issue Type: Improvement
Reporter: Remo Gloor
Priority: Minor
Currently delayed messages are delivered even if the session it was sent in
is rolled back. According to
http://activemq.2283324.n4.nabble.com/AMQ-SCHEDULED-DELAY-and-transactional-boundaries-td4658339.html
this is because the message can be delivered far in the future and the
transaction would take to long.
I don't agree with that argument. The transaction can be short living. It is
only the enqueuing of the delayed message in the broker that has to be part
of the transaction. The delivery to the consumer is not part of the
transaction anymore.
e.g. consider the scenario in the following preudo code:
while (application_runs)
try{
msg = session.Receive();
session.SendDelayed(anotherMessage);
if (random(5) != 0) throw exception;
session.Commit();
} catch { session.Rollback; }
Currently a delayed message is sent for each retry. So we will get a lot more
messages in the future as we would expect. When delayed messages would
respect transactions just the successful ones would be enqueued. The other
ones are rolledback with the transaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582323#comment-13582323 ] Timothy Bish commented on AMQ-4335: --- Did you ensure you edited the xml file that's actually in use? Have you tried omitting the maxFrameSize option altogether? Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- 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-4332) LargeQueueSparseDeleteTest gets timeouts on testMoveMessages and testRemoveMessages
[ https://issues.apache.org/jira/browse/AMQ-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582329#comment-13582329 ] Timothy Bish commented on AMQ-4332: --- Applied changes to the tests. LargeQueueSparseDeleteTest gets timeouts on testMoveMessages and testRemoveMessages --- Key: AMQ-4332 URL: https://issues.apache.org/jira/browse/AMQ-4332 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor Attachments: AMQ4332.patch Both of these test have 10 second timeouts, but while occasionally completing in 6-7 seconds, generally are averaging 10-12. I'll attach a patch which bumps up the timeouts, but if you want I can add a bug to look into a possible performance issue here. I ran these tests against the 5.7 fuse branch and they averaged 4-5 seconds. -- 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] (AMQ-4327) XMPP Connector does not work with ActiveMQ 5.7
[ https://issues.apache.org/jira/browse/AMQ-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4327. - Resolution: Not A Problem You need to place the activemq-xmpp jar into the classpath so that the transport's factory finder file is available. Note that XMPP module is deprecated and will be removed in v5.9 XMPP Connector does not work with ActiveMQ 5.7 -- Key: AMQ-4327 URL: https://issues.apache.org/jira/browse/AMQ-4327 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.7.0 Environment: Windows Reporter: lokesh Fix For: 5.x Hi, When I send a message to xmpp queue. I get the following exception. I am using activemq version 5.7 SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Caught: javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [xmpp] javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [xmpp] at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:35) at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:252) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:265) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:238) at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:184) at App$HelloWorldProducer.run(App.java:41) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Transport scheme NOT recognized: [xmpp] at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27) at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:196) at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:66) at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:250) ... 5 more Caused by: java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/transport/xmpp at org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:96) at org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:58) at org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:146) at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:193) ... 7 more -- 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] (AMQ-4318) activemq-broker throws KahaDB error
[ https://issues.apache.org/jira/browse/AMQ-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4318. - Resolution: Not A Problem If not using activemq-all you need to add the activemq-kahadb-store dependency to you project as that's where the KahaDB persistence adapter is located. activemq-broker throws KahaDB error --- Key: AMQ-4318 URL: https://issues.apache.org/jira/browse/AMQ-4318 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Jesse Bowes I just tried updating to 2.8.0 using the new activemq-broker and activemq-client modules instead of the previous activemq-core and get a KahaDB exception (see below). Using activemq-all works. Just naively trying add the latest kahadb to my pom didn't correct the issue. I'm making the following calls: ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(vm://localhost); connection = connectionFactory.createConnection(); connection.start(); session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 364 [main] ERROR org.apache.activemq.broker.BrokerService - Failed to start Apache ActiveMQ (localhost, null). Reason: ava.io.IOException: org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter java.io.IOException: org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) at org.apache.activemq.broker.BrokerService.createPersistenceAdapter(BrokerService.java:2215) at org.apache.activemq.broker.BrokerService.getPersistenceAdapter(BrokerService.java:) at org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:592) at org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:587) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:552) at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:124) at org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:54) at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64) at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:250) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:265) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:238) at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:184) at com.boeing.uclass.mcs.comm.UclassJMSCommManager.start(UclassJMSCommManager.java:100) at com.boeing.uclass.uclass.inttest.CommListenerTest.SenderListenerTest(CommListenerTest.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at
[jira] [Commented] (AMQ-4316) Problem with duplicate message detection using ObjectMessage with equal object
[
https://issues.apache.org/jira/browse/AMQ-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582334#comment-13582334
]
Timothy Bish commented on AMQ-4316:
---
Please create and attach a unit tests that demonstrates the issue you are
seeing.
Problem with duplicate message detection using ObjectMessage with equal object
--
Key: AMQ-4316
URL: https://issues.apache.org/jira/browse/AMQ-4316
Project: ActiveMQ
Issue Type: Bug
Components: Broker, Message Store
Affects Versions: 5.8.0
Environment: Activemq 5.8.0, Kahadb store.
Reporter: Pether Sörling
Priority: Critical
When sending any ObjectMessage that contain an equal object to was been sent
before I get from KahaDBStore : Duplicate message add attempt rejected.
So even if the messageId and commandId is different the message is still
detected as a duplicate and ignored.
A simple test would be to create two objectmessages with
session.createObjectMessage(ANY OBJECT THAT is Equal) and send to a
queue.
Our code worked with version 5.7.0 and tested amq-store as well as
KahaDbstore.
-- activemq config--
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:aop=http://www.springframework.org/schema/aop;
xmlns:context=http://www.springframework.org/schema/context;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:jms=http://www.springframework.org/schema/jms;
xmlns:tx=http://www.springframework.org/schema/tx;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core-5.4.1.xsd
http://www.springframework.org/schema/jms
http://www.springframework.org/schema/jms/spring-jms-3.0.xsd;
!-- lets create an embedded ActiveMQ Broker --
amq:broker brokerName=broker id=broker useJmx=true
useShutdownHook=false
persistent=true enableStatistics=true
!-- add network
http://activemq.apache.org/networks-of-brokers.html --
amq:persistenceAdapter
amq:kahaDB directory=activemq-data/broker/KahaDB
journalMaxFileLength=32mb/
/amq:persistenceAdapter
amq:networkConnectors
amq:networkConnector
uri=${server.activemq.networkconnectors.uri} /
/amq:networkConnectors
amq:destinationPolicy
amq:policyMap
amq:policyEntries
amq:policyEntry queue=
optimizedDispatch=true
lazyDispatch=false
producerFlowControl=false memoryLimit=128 mb
strictOrderDispatch=true
amq:dispatchPolicy
amq:strictOrderDispatchPolicy /
/amq:dispatchPolicy
amq:messageGroupMapFactory
amq:simpleMessageGroupMapFactory /
/amq:messageGroupMapFactory
amq:subscriptionRecoveryPolicy
amq:timedSubscriptionRecoveryPolicy
recoverDuration=36 /
/amq:subscriptionRecoveryPolicy
/amq:policyEntry
/amq:policyEntries
/amq:policyMap
/amq:destinationPolicy
amq:systemUsage
amq:systemUsage sendFailIfNoSpace=true
amq:memoryUsage
amq:memoryUsage limit=256mb /
/amq:memoryUsage
amq:storeUsage
amq:storeUsage limit=0 /
/amq:storeUsage
amq:tempUsage
amq:tempUsage limit=4096mb /
/amq:tempUsage
/amq:systemUsage
[jira] [Resolved] (AMQ-4315) Duplicate files in distribution
[ https://issues.apache.org/jira/browse/AMQ-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4315. --- Resolution: Fixed Duplicate files in distribution --- Key: AMQ-4315 URL: https://issues.apache.org/jira/browse/AMQ-4315 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Jim Gomes Priority: Minor Fix For: 5.x There are a couple of duplicate files in the ActiveMQ 5.8.0 distribution package. Here are the locations: lib/extra/activemq-leveldb-store-5.8.0.jar lib/optional/activemq-leveldb-store-5.8.0.jar lib/activemq-spring-5.8.0.jar lib/optional/activemq-spring-5.8.0.jar Not sure which location is the real location. -- 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] (AMQ-4245) MDB MaxSessions slowly dwindles on delivery failure
[ https://issues.apache.org/jira/browse/AMQ-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4245. - Resolution: Incomplete No test or further information given to help with this. MDB MaxSessions slowly dwindles on delivery failure --- Key: AMQ-4245 URL: https://issues.apache.org/jira/browse/AMQ-4245 Project: ActiveMQ Issue Type: Bug Components: Connector Affects Versions: 5.7.0 Reporter: David Blevins It appears that if the transaction associated with an MDB rollsback (delivery failure) then maxSession effectively gets reduced by 1. It would be great if maxSessions was guaranteed throughout the life of the deployed MDB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582371#comment-13582371 ] Pat Flaherty commented on AMQ-4335: --- Hi Tim, First off thanks for responding to our query. The xml file I'm editing is /conf/activemq.xml. I just tried omitting the maxFrameSize altogether and I receive the same error (Frame size of 140MB larger than max allowed 100MB) The line after editing looks like this: transportConnector name=openwire uri=tcp://192.168.10.1:61616? maximumConnections=1000/ I also tried making it smaller than 100MB and the message is the same (Frame size of 140MB larger than max allowed 100MB) which seem to indicate it is not reading it or as you asked in the first question am I editing the xml file in use. I think I am editing the right xml because the logs reflect my changed to the frame size. Any insight is much appreciated Thanks Pat Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582387#comment-13582387 ] Timothy Bish commented on AMQ-4335: --- Can you put together a little unit test showing the problem? Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- 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
[VOTE] Release Apache Apollo 1.6
Hi Everyone,
I've deployed a 1.6 release candidate to pickup fixes and new features
since the 1.5 release. It would be nice to release this before Apache Con
NA.
This release features improvements like:
* [APLO-275] - Add AMQP 1.0 Protocol Support
* [APLO-273] - STOMP 1.1 Over WebSocket
* [APLO-268] - Examples for stompest Python STOMP client
* [APLO-280] - Clarification about message groups
* [APLO-19] - Support message groups
* [APLO-271] - Integrate jolokia into Apollo for nice REST based access to
JMX.
* [APLO-272] - Support creating topics and queues via the REST management
api.
* [APLO-274] - Support accessing environment variables via \${env.*}
references in the the config file.
* [APLO-278] - Support option on queues to control if a round robin message
distribution strategy should be used when multiple consumer are attached to
the queue.
Full Changlog available at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311310version=12322470
The release candidate has been staged to nexus under:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/
Source code distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apollo-project/1.6/
Binary distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apache-apollo/1.6/
The build was tagged at:
http://svn.apache.org/repos/asf/activemq/activemq-apollo/tags/apollo-project-1.6/
The project website for that version has been staged to:
http://activemq.apache.org/apollo/versions/1.6/website/index.html
Please vote to approve this release
[ ] +1 Release Apache Apollo 1.6
[ ] -1 Veto the release (provide specific comments)
As usual, the vote will be open for at least 72 hours.
Here's my +1
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchir...@redhat.com hchir...@redhat.com | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirinohttp://twitter.com/hiramchirino
*
*blog: Hiram Chirino's Bit Mojo http://hiramchirino.com/blog/*
[jira] [Commented] (AMQ-2040) Improve message browsing
[ https://issues.apache.org/jira/browse/AMQ-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582478#comment-13582478 ] Christian Müller commented on AMQ-2040: --- Today I hit the same/similar issue with ActiveMQ 5.7.0. I browse a queue (1000 messages) with a message selector which match the first and the last message. However, I only got the first one. I guess because the message selector is only executed on the 200 fetch messages. Right? Any plans to improve this? Improve message browsing Key: AMQ-2040 URL: https://issues.apache.org/jira/browse/AMQ-2040 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.2.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: NEEDS_REVIEWED Currently the browse() method returns 400 messages (or all if there are less than that). Allow configuring the number of messages returned and fetching messages beyond first page with the method such as browse(int page). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4122) Lease Database Locker failover broken
[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582509#comment-13582509 ] Gary Tully commented on AMQ-4122: - @st.h - that is not expected unless all of the brokers have the same name. I would be great to see a sql log of the db for the lock table as the nodes attempt to get the lock Lease Database Locker failover broken - Key: AMQ-4122 URL: https://issues.apache.org/jira/browse/AMQ-4122 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Environment: Java 7u9, SUSE 11, Mysql Reporter: st.h Assignee: Gary Tully Fix For: 5.8.0 Attachments: activemq-kyle.xml, activemq.xml, activemq.xml We are using ActiveMQ 5.7.0 together with a mysql database and could not observe correct failover behavior with lease database locker. It seems that there is a race condition, which prevents the correct failover procedure. We noticed that when starting up two instances, both instance are becoming master. We did several test, including the following and could not observe intended functionality: - shutdown all instances - manipulate database lock that one node has lock and set expiry time in distance future - start up both instances. both instances are unable to acquire lock, as the lock hasn't expired, which should be correct behavior. - update the expiry time in database, so that the lock is expired. - first instance notices expired lock and becomes master - when second instance checks for lock, it also updates the database and becomes master. To my understanding the second instance should not be able to update the lock, as it is held by the first instance and should not be able to become master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache Apollo 1.6
+1
On Wed, Feb 20, 2013 at 10:49 AM, Hiram Chirino hi...@hiramchirino.comwrote:
Hi Everyone,
I've deployed a 1.6 release candidate to pickup fixes and new features
since the 1.5 release. It would be nice to release this before Apache Con
NA.
This release features improvements like:
* [APLO-275] - Add AMQP 1.0 Protocol Support
* [APLO-273] - STOMP 1.1 Over WebSocket
* [APLO-268] - Examples for stompest Python STOMP client
* [APLO-280] - Clarification about message groups
* [APLO-19] - Support message groups
* [APLO-271] - Integrate jolokia into Apollo for nice REST based access to
JMX.
* [APLO-272] - Support creating topics and queues via the REST management
api.
* [APLO-274] - Support accessing environment variables via \${env.*}
references in the the config file.
* [APLO-278] - Support option on queues to control if a round robin message
distribution strategy should be used when multiple consumer are attached to
the queue.
Full Changlog available at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311310version=12322470
The release candidate has been staged to nexus under:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/
Source code distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apollo-project/1.6/
Binary distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apache-apollo/1.6/
The build was tagged at:
http://svn.apache.org/repos/asf/activemq/activemq-apollo/tags/apollo-project-1.6/
The project website for that version has been staged to:
http://activemq.apache.org/apollo/versions/1.6/website/index.html
Please vote to approve this release
[ ] +1 Release Apache Apollo 1.6
[ ] -1 Veto the release (provide specific comments)
As usual, the vote will be open for at least 72 hours.
Here's my +1
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchir...@redhat.com hchir...@redhat.com | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino
http://twitter.com/hiramchirino
*
*blog: Hiram Chirino's Bit Mojo http://hiramchirino.com/blog/*
[jira] [Created] (AMQ-4338) MQTTSSLTest has multiple test cases that fail frequently
Kevin Earls created AMQ-4338: Summary: MQTTSSLTest has multiple test cases that fail frequently Key: AMQ-4338 URL: https://issues.apache.org/jira/browse/AMQ-4338 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor MQTTSSLTest has multiple different test cases (including testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the provider.connect() call in initializeConnection() as shown in the stacktrace below. Another problem with this test is it was giving a misleading error when run under Hudson, showing that the test that followed it (MQTTTest) was failing instead. I think this was because of the way it was using AutoFailTestSupport. I will attach a patch which removes that and uses timeouts on @Test annotations instead. testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest) Time elapsed: 30.004 sec ERROR! java.lang.Exception: test timed out after 3 milliseconds at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at org.fusesource.mqtt.client.Promise.await(Promise.java:88) at org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49) at org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39) at org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60) Results : Tests in error: MQTTSSLTestAbstractMQTTTest.testSendAndReceiveLargeMessages:247-initializeConnection:60 » -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4338) MQTTSSLTest has multiple test cases that fail frequently
[ https://issues.apache.org/jira/browse/AMQ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Earls updated AMQ-4338: - Attachment: AMQ-4338.patch MQTTSSLTest has multiple test cases that fail frequently Key: AMQ-4338 URL: https://issues.apache.org/jira/browse/AMQ-4338 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor Attachments: AMQ-4338.patch MQTTSSLTest has multiple different test cases (including testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the provider.connect() call in initializeConnection() as shown in the stacktrace below. Another problem with this test is it was giving a misleading error when run under Hudson, showing that the test that followed it (MQTTTest) was failing instead. I think this was because of the way it was using AutoFailTestSupport. I will attach a patch which removes that and uses timeouts on @Test annotations instead. testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest) Time elapsed: 30.004 sec ERROR! java.lang.Exception: test timed out after 3 milliseconds at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at org.fusesource.mqtt.client.Promise.await(Promise.java:88) at org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49) at org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39) at org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60) Results : Tests in error: MQTTSSLTestAbstractMQTTTest.testSendAndReceiveLargeMessages:247-initializeConnection:60 » -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache Apollo 1.6
+1
On 02/20/2013 01:49 PM, Hiram Chirino wrote:
Hi Everyone,
I've deployed a 1.6 release candidate to pickup fixes and new features
since the 1.5 release. It would be nice to release this before Apache Con
NA.
This release features improvements like:
* [APLO-275] - Add AMQP 1.0 Protocol Support
* [APLO-273] - STOMP 1.1 Over WebSocket
* [APLO-268] - Examples for stompest Python STOMP client
* [APLO-280] - Clarification about message groups
* [APLO-19] - Support message groups
* [APLO-271] - Integrate jolokia into Apollo for nice REST based access to
JMX.
* [APLO-272] - Support creating topics and queues via the REST management
api.
* [APLO-274] - Support accessing environment variables via \${env.*}
references in the the config file.
* [APLO-278] - Support option on queues to control if a round robin message
distribution strategy should be used when multiple consumer are attached to
the queue.
Full Changlog available at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311310version=12322470
The release candidate has been staged to nexus under:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/
Source code distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apollo-project/1.6/
Binary distros can be found at:
https://repository.apache.org/content/repositories/orgapacheactivemq-278/org/apache/activemq/apache-apollo/1.6/
The build was tagged at:
http://svn.apache.org/repos/asf/activemq/activemq-apollo/tags/apollo-project-1.6/
The project website for that version has been staged to:
http://activemq.apache.org/apollo/versions/1.6/website/index.html
Please vote to approve this release
[ ] +1 Release Apache Apollo 1.6
[ ] -1 Veto the release (provide specific comments)
As usual, the vote will be open for at least 72 hours.
Here's my +1
--
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-4122) Lease Database Locker failover broken
[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582517#comment-13582517 ] st.h commented on AMQ-4122: --- I have configured ActiveMQ to use the hostnames. The master correctly shows up with its hostname in the DB, so that should be good. Is it possible to configure ActiveMQ to log the sql statements, or do you need the DBs log? The latter one might be a problem here. Lease Database Locker failover broken - Key: AMQ-4122 URL: https://issues.apache.org/jira/browse/AMQ-4122 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Environment: Java 7u9, SUSE 11, Mysql Reporter: st.h Assignee: Gary Tully Fix For: 5.8.0 Attachments: activemq-kyle.xml, activemq.xml, activemq.xml We are using ActiveMQ 5.7.0 together with a mysql database and could not observe correct failover behavior with lease database locker. It seems that there is a race condition, which prevents the correct failover procedure. We noticed that when starting up two instances, both instance are becoming master. We did several test, including the following and could not observe intended functionality: - shutdown all instances - manipulate database lock that one node has lock and set expiry time in distance future - start up both instances. both instances are unable to acquire lock, as the lock hasn't expired, which should be correct behavior. - update the expiry time in database, so that the lock is expired. - first instance notices expired lock and becomes master - when second instance checks for lock, it also updates the database and becomes master. To my understanding the second instance should not be able to update the lock, as it is held by the first instance and should not be able to become master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4122) Lease Database Locker failover broken
[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582563#comment-13582563 ] Gary Tully commented on AMQ-4122: - @st.h was thinking the latter. Or maybe there is a logging sql driver or wrapper. The broker does not provide this, well not the data in prepared statements which is the interesting part. For that reason, the logs from the DB is best. And the DB is common to all brokers so it should provide the interesting overlap etc. Lease Database Locker failover broken - Key: AMQ-4122 URL: https://issues.apache.org/jira/browse/AMQ-4122 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Environment: Java 7u9, SUSE 11, Mysql Reporter: st.h Assignee: Gary Tully Fix For: 5.8.0 Attachments: activemq-kyle.xml, activemq.xml, activemq.xml We are using ActiveMQ 5.7.0 together with a mysql database and could not observe correct failover behavior with lease database locker. It seems that there is a race condition, which prevents the correct failover procedure. We noticed that when starting up two instances, both instance are becoming master. We did several test, including the following and could not observe intended functionality: - shutdown all instances - manipulate database lock that one node has lock and set expiry time in distance future - start up both instances. both instances are unable to acquire lock, as the lock hasn't expired, which should be correct behavior. - update the expiry time in database, so that the lock is expired. - first instance notices expired lock and becomes master - when second instance checks for lock, it also updates the database and becomes master. To my understanding the second instance should not be able to update the lock, as it is held by the first instance and should not be able to become master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (AMQ-4000) Durable subscription not getting unregistered on networked broker
[ https://issues.apache.org/jira/browse/AMQ-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reopened AMQ-4000: - I reverted the change, we can revisit. Durable subscription not getting unregistered on networked broker - Key: AMQ-4000 URL: https://issues.apache.org/jira/browse/AMQ-4000 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.6.0 Environment: network of brokers, durable topic subscriptions. Reporter: Torsten Mielke Assignee: Christian Posta Labels: durable_subscription, networks Attachments: JUnitTest.patch In a network of two brokers, a durable subscription is correctly propagated across to the remote broker. However when the consumer unsubscribes from the durable subscription again, it is only removed on the local broker but not on the remote broker. The remote broker keeps its durable subscription alive. As a consequence messages sent to the topic destination on the remote broker for which the durable subscriptions existed, are passed on to the local broker, although there is no active subscription on the local broker. The local broker will discard these msgs but unnecessary traffic has already occurred on the network bridge. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582572#comment-13582572 ] Pat Flaherty commented on AMQ-4335: --- Hi Tim, We can try and do that. Is there not an easy way for you to test this functionality? Thanks Pat Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582575#comment-13582575 ] Timothy Bish commented on AMQ-4335: --- A unit test would save me the time of having to create a test case, otherwise I will try to get to it when time permits. Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pat Flaherty updated AMQ-4335: -- Attachment: BugInActivemq.zip Hi Tim, Lucille here wrote a test case for this apparent bug. See attached zip file. The zip file contains the following: -The 140MB JSON message we are trying to send. - My activemq.xml with the following changes: policyEntry queue= producerFlowControl=true memoryLimit=20mb (Defaults to 1MB) managementContext createConnector=true/ (We set this to true for management purposes) memoryUsage limit=950 mb/ (We goose this from the 64MB default) transportConnector name=openwire uri=tcp://0.0.0.0:61616? maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ (Goose to 150MB to handle 140MB message) transportConnector name=amqp uri=amqp://0.0.0.0:5672? maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ (Also goosed this connector to 150MB although it is not really necessary) - The test case source called TestActiveMqProducer.java. I hope this helps. Thanks again for looking into this for us. -Pat Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Attachments: BugInActivemq.zip Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4338) MQTTSSLTest has multiple test cases that fail frequently
[ https://issues.apache.org/jira/browse/AMQ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582646#comment-13582646 ] Timothy Bish commented on AMQ-4338: --- Added the patch, guess we need to figure out why these are all failing now. MQTTSSLTest has multiple test cases that fail frequently Key: AMQ-4338 URL: https://issues.apache.org/jira/browse/AMQ-4338 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor Attachments: AMQ-4338.patch MQTTSSLTest has multiple different test cases (including testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the provider.connect() call in initializeConnection() as shown in the stacktrace below. Another problem with this test is it was giving a misleading error when run under Hudson, showing that the test that followed it (MQTTTest) was failing instead. I think this was because of the way it was using AutoFailTestSupport. I will attach a patch which removes that and uses timeouts on @Test annotations instead. testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest) Time elapsed: 30.004 sec ERROR! java.lang.Exception: test timed out after 3 milliseconds at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at org.fusesource.mqtt.client.Promise.await(Promise.java:88) at org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49) at org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39) at org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60) Results : Tests in error: MQTTSSLTestAbstractMQTTTest.testSendAndReceiveLargeMessages:247-initializeConnection:60 » -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-4335: -- Attachment: amq4335.xml AMQ4335Test.java Created a JUnit test case and from what I can see things are working. Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Attachments: AMQ4335Test.java, amq4335.xml, BugInActivemq.zip Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582697#comment-13582697 ] Pat Flaherty commented on AMQ-4335: --- Hi Tim, You created the Junit test case from what we supplied or did you build your own version? Thanks Pat Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Attachments: AMQ4335Test.java, amq4335.xml, BugInActivemq.zip Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582727#comment-13582727 ] Timothy Bish commented on AMQ-4335: --- Yours isn't a JUnit test case so it can't be dropped into the ActiveMQ unit tests. You're welcome to use what I did to create an actual unit test. Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Attachments: AMQ4335Test.java, amq4335.xml, BugInActivemq.zip Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4335) Cannot set maxFrameSize greater than 100MB
[ https://issues.apache.org/jira/browse/AMQ-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582764#comment-13582764 ] Pat Flaherty commented on AMQ-4335: --- Hi Tim, 1. Forgive my ignorance but please tell how I can use what you did to create an actual unit test. 2. So do you think we have misconfigure something? Is there anyway for you to use the code we sent to see if you can reproduce what we are seeing? Thanks again, Pat Cannot set maxFrameSize greater than 100MB -- Key: AMQ-4335 URL: https://issues.apache.org/jira/browse/AMQ-4335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Windows 2008 R2 Reporter: Pat Flaherty Attachments: AMQ4335Test.java, amq4335.xml, BugInActivemq.zip Trying to send JSON messages greater then 100MB and I receive the error: Transport Connection to: tcp://192.168.10.1:55823 failed: java.io.IOException: Frame size of 140 MB larger than max allowed 100 MB I tried increasing the frame size in 5.8.0 as follows: transportConnectors !-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -- transportConnector name=openwire uri=tcp://192.168.10.1:61616?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ transportConnector name=amqp uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireformat.maxFrameSize=157286400/ /transportConnectors -- 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 still unstable: ActiveMQ-Java7 » ActiveMQ :: HTTP Protocol Support #145
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-http/145/
Jenkins build is back to stable : ActiveMQ-Java7 » ActiveMQ :: Unit Tests #145
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-unit-tests/145/changes
Jenkins build is still unstable: ActiveMQ-Java7 #145
See https://builds.apache.org/job/ActiveMQ-Java7/changes
Jenkins build is still unstable: ActiveMQ-Java7 » ActiveMQ :: Assembly #145
See https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$apache-activemq/145/
