Build failed in Jenkins: ActiveMQ » ActiveMQ :: STOMP Protocol #1518

2014-09-09 Thread Apache Jenkins Server 
See 


--
[00:38:57] [INFO]   
  
[INFO] 
[INFO] Building ActiveMQ :: STOMP Protocol 5.11-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-stomp ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-stomp ---
[INFO] 
[INFO] --- maven-consolets-plugin:1.30:install (default) @ activemq-stomp ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-stomp ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ activemq-stomp 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-stomp ---
[00:38:59] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ activemq-stomp 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 24 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-stomp ---
[00:39:00] [debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
activemq-stomp ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 30 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.16:test (default-test) @ activemq-stomp ---
[INFO] Surefire report directory: 

[00:39:02] 
[00:39:02] ---
[00:39:02]  T E S T S
[00:39:02] ---
[00:39:02] 
[00:39:02] ---
[00:39:02]  T E S T S
[00:39:02] ---
[00:39:03] Running org.apache.activemq.transport.stomp.ConnectTest
[00:39:11] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
8.169 sec - in org.apache.activemq.transport.stomp.ConnectTest
[00:39:11] Running org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
[00:40:26] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
74.77 sec - in org.apache.activemq.transport.stomp.Stomp11NIOSSLTest
[00:40:27] Running org.apache.activemq.transport.stomp.Stomp11NIOTest
[00:41:41] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
74.553 sec - in org.apache.activemq.transport.stomp.Stomp11NIOTest
[00:41:42] Running org.apache.activemq.transport.stomp.Stomp11SslAuthTest
[00:42:57] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
75.652 sec - in org.apache.activemq.transport.stomp.Stomp11SslAuthTest
[00:42:58] Running org.apache.activemq.transport.stomp.Stomp11Test
[00:44:13] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
74.952 sec - in org.apache.activemq.transport.stomp.Stomp11Test
[00:44:13] Running org.apache.activemq.transport.stomp.Stomp12NIOSSLTest
[00:44:22] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
9.169 sec - in org.apache.activemq.transport.stomp.Stomp12NIOSSLTest
[00:44:23] Running org.apache.activemq.transport.stomp.Stomp12NIOTest
[00:44:32] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
8.727 sec - in org.apache.activemq.transport.stomp.Stomp12NIOTest
[00:44:32] Running org.apache.activemq.transport.stomp.Stomp12SslAuthTest
[00:44:43] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
10.895 sec - in org.apache.activemq.transport.stomp.Stomp12SslAuthTest
[00:44:44] Running org.apache.activemq.transport.stomp.Stomp12Test
[00:44:52] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
8.525 sec - in org.apache.activemq.transport.stomp.Stomp12Test
[00:44:53] Running org.apache.activemq.transport.stomp.StompAdvisoryTest
[00:45:01] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
8.346 sec - in org.apache.activemq.transport.stomp.StompAdvisoryTest
[00:45:01] Running org.apache.activemq.transport.stomp.StompFrameTest
[00:45:01]

Build failed in Jenkins: ActiveMQ #1518

2014-09-09 Thread Apache Jenkins Server 
See 

Changes:

[tabish121] https://issues.apache.org/jira/browse/AMQ-5350

[rajdavies] added CamelRoutesBrokerPlugin for 
https://issues.apache.org/jira/browse/AMQ-5351

[tabish121] https://issues.apache.org/jira/browse/AMQ-5352

[dkulp] [AMQ-5353] Use the same version range for the imports and the 
features.xml

--
[...truncated 1849 lines...]
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:958)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:822)
... 34 more
Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
The forked VM terminated without saying properly goodbye. VM crash or 
System.exit called ?
Command was/bin/sh -c cd 
 && 
/home/jenkins/tools/java/jdk1.7.0_25-32/jre/bin/java -jar 

 

 

at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:300)
... 37 more
Caused by: java.lang.RuntimeException: The forked VM terminated without saying 
properly goodbye. VM crash or System.exit called ?
Command was/bin/sh -c cd 
 && 
/home/jenkins/tools/java/jdk1.7.0_25-32/jre/bin/java -jar 

 

 

at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:485)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:352)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$300(ForkStarter.java:85)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:288)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:283)
... 5 more
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :activemq-stomp

[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-unit-tests/5.11-SNAPSHOT/activemq-unit-tests-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Unit Tests #1515
Archived 1 artifacts
Archive block size is 32768
Received 1 blocks and 37668 bytes
Compression is 46.5%
Took 2.2 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-openwire-legacy/5.11-SNAPSHOT/activemq-openwire-legacy-5.11-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.activemq/activemq-openwire-legacy/5.11-SNAPSHOT/activemq-openwire-legacy-5.11-SNAPSHOT.jar
No artifacts from ActiveMQ ? ActiveMQ :: Openwire Legacy Support #1517 to 
compare, so performing full copy of artifacts
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-web-console/5.11-SNAPSHOT/activemq-web-console-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Web Console #1515
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 10505 bytes
Compression is 0.0%
Took 2.2 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/activemq-web-demo/5.11-SNAPSHOT/activemq-web-demo-5.11-SNAPSHOT.pom
Sending artifact delta relative to ActiveMQ ? ActiveMQ :: Web Demo #1515
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 8321 bytes
Compression is 0.0%
Took 0.31 sec
[JENKINS] Archiving 
 to 
org.apache.activemq/active

[jira] [Commented] (AMQ-5185) Duplicate messages occur for MQTT cleanSession=false client with network of brokers

2014-09-09 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-5185:
---

The workaround transparently subscribes the connect client to a Queue linked to 
the virtual topic in question, there's nothing the client needs to do, on its 
end everything still appears to be Topic based. 

> Duplicate messages occur  for MQTT cleanSession=false client with network of 
> brokers 
> -
>
> Key: AMQ-5185
> URL: https://issues.apache.org/jira/browse/AMQ-5185
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.9.1
> Environment: Linux. Python client using MQTT Paho library version 0.9
>Reporter: Paddy
>  Labels: mqtt
>
> Duplicates delivery of messages occur when connecting to a network of brokers 
> with an MQTT client with cleansession=false.
> Steps to reproduce test:
> 1. Form network of brokers A and B
> 2. Connect "client1" with cleansession=false to broker A and subscribe to 
> topic "paho/test". Make sure client_id is set to "client1".
> 3. Disconnect client1
> 4. Connect "client2" to broker A and publish single message "hello" to topic 
> "paho/test".
> 5. Connect "client1" to broker A and subscribe to "paho/test". Message 
> "hello" would be received.
> 6. Disconnect "client1"
> 7. Connect "client1" to broker B and subscribe to "paho/test". Message 
> "hello" would be received (again).
> Behavior is the same for publishing with qos=0,1,2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5185) Duplicate messages occur for MQTT cleanSession=false client with network of brokers

2014-09-09 Thread Paddy (JIRA) 

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

Paddy commented on AMQ-5185:


virtual topic workaround requires consumers to use queues and MQTT clients do 
not have the concept of queues. Only topics are supported in MQTT.

> Duplicate messages occur  for MQTT cleanSession=false client with network of 
> brokers 
> -
>
> Key: AMQ-5185
> URL: https://issues.apache.org/jira/browse/AMQ-5185
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.9.1
> Environment: Linux. Python client using MQTT Paho library version 0.9
>Reporter: Paddy
>  Labels: mqtt
>
> Duplicates delivery of messages occur when connecting to a network of brokers 
> with an MQTT client with cleansession=false.
> Steps to reproduce test:
> 1. Form network of brokers A and B
> 2. Connect "client1" with cleansession=false to broker A and subscribe to 
> topic "paho/test". Make sure client_id is set to "client1".
> 3. Disconnect client1
> 4. Connect "client2" to broker A and publish single message "hello" to topic 
> "paho/test".
> 5. Connect "client1" to broker A and subscribe to "paho/test". Message 
> "hello" would be received.
> 6. Disconnect "client1"
> 7. Connect "client1" to broker B and subscribe to "paho/test". Message 
> "hello" would be received (again).
> Behavior is the same for publishing with qos=0,1,2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5353) Mismatch of camel versions allowed

2014-09-09 Thread Daniel Kulp (JIRA) 
Daniel Kulp created AMQ-5353:


 Summary: Mismatch of camel versions allowed
 Key: AMQ-5353
 URL: https://issues.apache.org/jira/browse/AMQ-5353
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-camel, OSGi/Karaf
Affects Versions: 5.10.0
Reporter: Daniel Kulp
Assignee: Daniel Kulp



The Karaf features file allows a Camel range of [2.12,3).   However, that range 
is not entered into the bundle plugin for the modules that import camel so they 
result in having a range of [2.13,3) precluding them from working with Camel 
2.12.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5080) RAR - missing messages on master slave failover

2014-09-09 Thread Fer Troya (JIRA) 

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

Fer Troya commented on AMQ-5080:


Hi [~gtully] I've noticed this commit refers to this fix as well 
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=207d4cdee682b65f3c434b51f440b1b6c28eefbd
 but it's commit date is the 28/Jul/14.

The release date for 5.10.0 is prior to that, as you can see in Maven Central 
http://central.maven.org/maven2/org/apache/activemq/activemq-rar/5.10.0/

When is this fix (containing the last commit) suppose to be delivered?
Is the Fix Version field wrong?

Thanks

> RAR - missing messages on master slave failover
> ---
>
> Key: AMQ-5080
> URL: https://issues.apache.org/jira/browse/AMQ-5080
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JCA Container
>Affects Versions: 5.9.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: 2PC, MDB, RAR, XA
> Fix For: 5.10.0
>
>
> With repeated failover between master and slave and mdb that consumers from A 
> and sends to B in a transaction we can -
> a) loose some messages acked as duplicates in error
> b) duplicate some messages when acks are lost in error but don't force a 
> rollback.
> A long running test that consumers/produces 20k messages with a failover 
> every 200 messages eventually shows up various problems. With XA recovery and 
> async completion - there are many code path variations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5352) AMQP messages published transactionally should be accepted using a TransactionalState

2014-09-09 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-5352.
---
   Resolution: Fixed
Fix Version/s: 5.11.0

Fixed on trunk.

> AMQP messages published transactionally should be accepted using a 
> TransactionalState
> -
>
> Key: AMQ-5352
> URL: https://issues.apache.org/jira/browse/AMQ-5352
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Fix For: 5.11.0
>
> Attachments: AMQ-5352.patch
>
>
> Currently, when an incoming AMQP message is part of a transaction, it is 
> accepted using the regular Accepted terminal state on the disposition reply. 
> According to the spec [1] the disposition should actually use a 
> TransactionalState with Accepted outcome.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AMQ-5352) AMQP messages published transactionally should be accepted using a TransactionalState

2014-09-09 Thread Timothy Bish (JIRA) 

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

Timothy Bish reassigned AMQ-5352:
-

Assignee: Timothy Bish

> AMQP messages published transactionally should be accepted using a 
> TransactionalState
> -
>
> Key: AMQ-5352
> URL: https://issues.apache.org/jira/browse/AMQ-5352
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Attachments: AMQ-5352.patch
>
>
> Currently, when an incoming AMQP message is part of a transaction, it is 
> accepted using the regular Accepted terminal state on the disposition reply. 
> According to the spec [1] the disposition should actually use a 
> TransactionalState with Accepted outcome.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

2014-09-09 Thread Jim Gomes 
+1

On Mon, Sep 8, 2014 at 7:43 AM, Timothy Bish  wrote:

> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.4
>
> This is a bug fix only release focusing on some issues with Consumers in
> local transacted sessions where messages were getting marked as duplicates
> in error after failover and some other edge cases that could lead to a
> missed redelivery.
>
> The binaries and source bundles for the Release Candidate can be found
> here:
> http://people.apache.org/~tabish/nms-1.6.0
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v164.html
>
> The list of issues resolved is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311201&version=12327446
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.4
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

[jira] [Updated] (AMQ-5352) AMQP messages published transactionally should be accepted using a TransactionalState

2014-09-09 Thread Robbie Gemmell (JIRA) 

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

Robbie Gemmell updated AMQ-5352:

Attachment: AMQ-5352.patch

Attaching patch which checks if the deliverystate was transactional and if so 
replies with a disposition using a TransactionalState containing the same 
txn-id and the Accepted outcome.

> AMQP messages published transactionally should be accepted using a 
> TransactionalState
> -
>
> Key: AMQ-5352
> URL: https://issues.apache.org/jira/browse/AMQ-5352
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Robbie Gemmell
> Attachments: AMQ-5352.patch
>
>
> Currently, when an incoming AMQP message is part of a transaction, it is 
> accepted using the regular Accepted terminal state on the disposition reply. 
> According to the spec [1] the disposition should actually use a 
> TransactionalState with Accepted outcome.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5352) AMQP messages published transactionally should be accepted using a TransactionalState

2014-09-09 Thread Robbie Gemmell (JIRA) 
Robbie Gemmell created AMQ-5352:
---

 Summary: AMQP messages published transactionally should be 
accepted using a TransactionalState
 Key: AMQ-5352
 URL: https://issues.apache.org/jira/browse/AMQ-5352
 Project: ActiveMQ
  Issue Type: Bug
  Components: AMQP
Affects Versions: 5.10.0
Reporter: Robbie Gemmell


Currently, when an incoming AMQP message is part of a transaction, it is 
accepted using the regular Accepted terminal state on the disposition reply. 
According to the spec [1] the disposition should actually use a 
TransactionalState with Accepted outcome.

[1] 
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5351) Create a Camel routes plugin to load routes dynamically into the broker

2014-09-09 Thread Rob Davies (JIRA) 

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

Rob Davies resolved AMQ-5351.
-
Resolution: Fixed

resolved by refs/heads/trunk b2e6a4166 -> 7ca25965d


> Create a Camel routes plugin to load routes dynamically into the broker
> ---
>
> Key: AMQ-5351
> URL: https://issues.apache.org/jira/browse/AMQ-5351
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Rob Davies
>Assignee: Rob Davies
> Fix For: 5.11.0
>
>
> The Broker camel component allows flexibility to change messaging internally 
> in the broker. To add more flexibility, allowing changes to a CamelContext 
> loaded by the plugin dynamically, will allow routes to modified on the fly 
> without restarting the broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5351) Create a Camel routes plugin to load routes dynamically into the broker

2014-09-09 Thread Rob Davies (JIRA) 
Rob Davies created AMQ-5351:
---

 Summary: Create a Camel routes plugin to load routes dynamically 
into the broker
 Key: AMQ-5351
 URL: https://issues.apache.org/jira/browse/AMQ-5351
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: Rob Davies
Assignee: Rob Davies
 Fix For: 5.11.0


The Broker camel component allows flexibility to change messaging internally in 
the broker. To add more flexibility, allowing changes to a CamelContext loaded 
by the plugin dynamically, will allow routes to modified on the fly without 
restarting the broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5350) Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize setting.

2014-09-09 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-5350:
---

No, it's not set unless the URI of the TransportConnector includes the 
wireFormat.maxAmqpFrameSize value.

> Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize 
> setting.
> 
>
> Key: AMQ-5350
> URL: https://issues.apache.org/jira/browse/AMQ-5350
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.11.0
>
>
> We currently set the maxFrameSize value in Proton using the WireFormat 
> maxFrameSize value.  This not the correct application of this property as it 
> is meant to control the max size a frame we will accept before we disconnect 
> a client whereas in AMQP this control how large a frame is before the 
> transport starts splitting the data into multiple frames.  
> Setting this value on Proton has other side effects like increased memory 
> utilization and decreased performance.  Instead of linking these we should 
> introduce an additional property on the AMQP WireFormat class to allow for 
> setting the maxAmqpFrameSize which defaults to no max.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5350) Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize setting.

2014-09-09 Thread clebert suconic (JIRA) 

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

clebert suconic commented on AMQ-5350:
--

do you still set maxFrameSize on the transport?


I found out that not setting it at all will make performance to be 10X better 
due to some issues on Proton. It's a bug on Proton probably and still not fixed.

> Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize 
> setting.
> 
>
> Key: AMQ-5350
> URL: https://issues.apache.org/jira/browse/AMQ-5350
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.11.0
>
>
> We currently set the maxFrameSize value in Proton using the WireFormat 
> maxFrameSize value.  This not the correct application of this property as it 
> is meant to control the max size a frame we will accept before we disconnect 
> a client whereas in AMQP this control how large a frame is before the 
> transport starts splitting the data into multiple frames.  
> Setting this value on Proton has other side effects like increased memory 
> utilization and decreased performance.  Instead of linking these we should 
> introduce an additional property on the AMQP WireFormat class to allow for 
> setting the maxAmqpFrameSize which defaults to no max.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5350) Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize setting.

2014-09-09 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-5350.
---
Resolution: Fixed

Fixed on trunk.

> Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize 
> setting.
> 
>
> Key: AMQ-5350
> URL: https://issues.apache.org/jira/browse/AMQ-5350
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.11.0
>
>
> We currently set the maxFrameSize value in Proton using the WireFormat 
> maxFrameSize value.  This not the correct application of this property as it 
> is meant to control the max size a frame we will accept before we disconnect 
> a client whereas in AMQP this control how large a frame is before the 
> transport starts splitting the data into multiple frames.  
> Setting this value on Proton has other side effects like increased memory 
> utilization and decreased performance.  Instead of linking these we should 
> introduce an additional property on the AMQP WireFormat class to allow for 
> setting the maxAmqpFrameSize which defaults to no max.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5350) Separate the AMQP maxFrameSize setting from the WireFormat maxFrameSize setting.

2014-09-09 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQ-5350:
-

 Summary: Separate the AMQP maxFrameSize setting from the 
WireFormat maxFrameSize setting.
 Key: AMQ-5350
 URL: https://issues.apache.org/jira/browse/AMQ-5350
 Project: ActiveMQ
  Issue Type: Bug
  Components: AMQP
Affects Versions: 5.10.0
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Minor
 Fix For: 5.11.0


We currently set the maxFrameSize value in Proton using the WireFormat 
maxFrameSize value.  This not the correct application of this property as it is 
meant to control the max size a frame we will accept before we disconnect a 
client whereas in AMQP this control how large a frame is before the transport 
starts splitting the data into multiple frames.  

Setting this value on Proton has other side effects like increased memory 
utilization and decreased performance.  Instead of linking these we should 
introduce an additional property on the AMQP WireFormat class to allow for 
setting the maxAmqpFrameSize which defaults to no max.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5349) Master broker stays without access to lease-database-locker

2014-09-09 Thread Jakub Korab (JIRA) 
Jakub Korab created AMQ-5349:


 Summary: Master broker stays without access to 
lease-database-locker
 Key: AMQ-5349
 URL: https://issues.apache.org/jira/browse/AMQ-5349
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
 Environment: RHEL 5.10, Oracle 10
Reporter: Jakub Korab


I have a master-slave setup running using a basic lease-database-locker config 
against an Oracle database.









When the network connection to the database is dropped, the master stays up, 
accepting messages (and throwing JMS exceptions). This  effect is that a slave 
is able to become a master in the meantime, without the clients failing over to 
it.

The broker should cease being the master if it cannot reach the database to 
extend its lease.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5349) Master broker stays up without access to lease-database-locker

2014-09-09 Thread Jakub Korab (JIRA) 

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

Jakub Korab updated AMQ-5349:
-
Summary: Master broker stays up without access to lease-database-locker  
(was: Master broker stays without access to lease-database-locker)

> Master broker stays up without access to lease-database-locker
> --
>
> Key: AMQ-5349
> URL: https://issues.apache.org/jira/browse/AMQ-5349
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.9.0
> Environment: RHEL 5.10, Oracle 10
>Reporter: Jakub Korab
>
> I have a master-slave setup running using a basic lease-database-locker 
> config against an Oracle database.
> 
>  dataSource="#oracle-ds" lockKeepAlivePeriod="5000">
> 
> 
> 
> 
> 
> When the network connection to the database is dropped, the master stays up, 
> accepting messages (and throwing JMS exceptions). This  effect is that a 
> slave is able to become a master in the meantime, without the clients failing 
> over to it.
> The broker should cease being the master if it cannot reach the database to 
> extend its lease.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

2014-09-09 Thread Gary Tully 
+1

On 8 September 2014 15:43, Timothy Bish  wrote:
> Hello
>
> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.6.4
>
> This is a bug fix only release focusing on some issues with Consumers in
> local transacted sessions where messages were getting marked as duplicates
> in error after failover and some other edge cases that could lead to a
> missed redelivery.
>
> The binaries and source bundles for the Release Candidate can be found here:
> http://people.apache.org/~tabish/nms-1.6.0
>
> The Wiki Page for this release is here:
> http://activemq.apache.org/nms/apachenmsactivemq-v164.html
>
> The list of issues resolved is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12327446
>
> Please cast your votes (the vote will be open for 72 hrs):
>
> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.6.4
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>



-- 
http://redhat.com
http://blog.garytully.com

Jenkins build is back to stable : ActiveMQ » ActiveMQ :: Spring #1517

2014-09-09 Thread Apache Jenkins Server 
See

Jenkins build is back to stable : ActiveMQ » ActiveMQ :: Generic JMS Pool #1517

2014-09-09 Thread Apache Jenkins Server 
See

ActiveMQ 5.9.2

2014-09-09 Thread Sobkowiak, Krzysztof 
Hi

Do you have any plans to release 5.9.2 in the future? There are only 2
commits, but the commits would solve one problem on ServiceMix 5.0.x and
would let us remove a workaround with the web console.

Kindly regards
Krzysztof

-- 
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini  | Software Solutions Center
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC