date:20130226

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

SuoNayi commented on AMQ-4122:
--

@Gary,verification is passed for amq 5.8.
I misread the parameter order for the lease obtain statement so I made a wrong
presumption.
Sorry for your time.

Lease Database Locker failover broken
-

Key: AMQ-4122
URL: https://issues.apache.org/jira/browse/AMQ-4122
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.7.0
Environment: Java 7u9, SUSE 11, Mysql
Reporter: st.h
Assignee: Gary Tully
Fix For: 5.8.0

Attachments: activemq-kyle.xml, activemq.xml, activemq.xml,
AMQ4122.patch, mysql.log

We are using ActiveMQ 5.7.0 together with a mysql database and could not
observe correct failover behavior with lease database locker.
It seems that there is a race condition, which prevents the correct failover
procedure.
We noticed that when starting up two instances, both instance are becoming
master.
We did several test, including the following and could not observe intended
functionality:
- shutdown all instances
- manipulate database lock that one node has lock and set expiry time in
distance future
- start up both instances. both instances are unable to acquire lock, as the
lock hasn't expired, which should be correct behavior.
- update the expiry time in database, so that the lock is expired.
- first instance notices expired lock and becomes master
- when second instance checks for lock, it also updates the database and
becomes master.
To my understanding the second instance should not be able to update the
lock, as it is held by the first instance and should not be able to become
master.

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

[jira] [Created] (AMQ-4347) Rename

SuoNayi created AMQ-4347:


 Summary: Rename 
 Key: AMQ-4347
 URL: https://issues.apache.org/jira/browse/AMQ-4347
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: SuoNayi




--
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-4347) Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition


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

SuoNayi updated AMQ-4347:
-

Description: 
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid  should be greater than leaseDuration to avoid 
unnecessary master/slave switching. 

  was:For lease database locker the lockKeepAlivePeriod property is the peroid 
to renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.


 Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition
 --

 Key: AMQ-4347
 URL: https://issues.apache.org/jira/browse/AMQ-4347
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Message Store
Affects Versions: 5.7.0, 5.8.0
Reporter: SuoNayi
Priority: Minor
 Fix For: 5.9.0


 For lease database locker the lockKeepAlivePeriod property is the peroid to 
 renew the lease and lockAcquireSleepInterval is the amount for lease 
 extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
 brings more intuition and readability.
 Besides, leaseRenewPeroid  should be greater than leaseDuration to avoid 
 unnecessary master/slave switching. 

--
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-4347) Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition


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

SuoNayi updated AMQ-4347:
-

Description: 
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
unnecessary master/slave switching. 

  was:
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid  should be greater than leaseDuration to avoid 
unnecessary master/slave switching. 


 Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition
 --

 Key: AMQ-4347
 URL: https://issues.apache.org/jira/browse/AMQ-4347
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Message Store
Affects Versions: 5.7.0, 5.8.0
Reporter: SuoNayi
Priority: Minor
 Fix For: 5.9.0


 For lease database locker the lockKeepAlivePeriod property is the peroid to 
 renew the lease and lockAcquireSleepInterval is the amount for lease 
 extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
 brings more intuition and readability.
 Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
 unnecessary master/slave switching. 

--
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-4347) Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition


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

SuoNayi updated AMQ-4347:
-

Description: 
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
unnecessary master/slave switching.
The users should be aware of unproper configuration via warning log.

  was:
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
unnecessary master/slave switching. 


 Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition
 --

 Key: AMQ-4347
 URL: https://issues.apache.org/jira/browse/AMQ-4347
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Message Store
Affects Versions: 5.7.0, 5.8.0
Reporter: SuoNayi
Priority: Minor
 Fix For: 5.9.0


 For lease database locker the lockKeepAlivePeriod property is the peroid to 
 renew the lease and lockAcquireSleepInterval is the amount for lease 
 extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
 brings more intuition and readability.
 Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
 unnecessary master/slave switching.
 The users should be aware of unproper configuration via warning log.

--
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-4347) Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition


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

SuoNayi updated AMQ-4347:
-

Description: 
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseDuration should be greater than leaseRenewPeroid to avoid 
unnecessary master/slave switching.
The users should be aware of unproper configuration via warning log.

  was:
For lease database locker the lockKeepAlivePeriod property is the peroid to 
renew the lease and lockAcquireSleepInterval is the amount for lease 
extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
brings more intuition and readability.
Besides, leaseRenewPeroid should be greater than leaseDuration to avoid 
unnecessary master/slave switching.
The users should be aware of unproper configuration via warning log.


 Rename lockKeepAlivePeriod and lockAcquireSleepInterval for more intuition
 --

 Key: AMQ-4347
 URL: https://issues.apache.org/jira/browse/AMQ-4347
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Message Store
Affects Versions: 5.7.0, 5.8.0
Reporter: SuoNayi
Priority: Minor
 Fix For: 5.9.0


 For lease database locker the lockKeepAlivePeriod property is the peroid to 
 renew the lease and lockAcquireSleepInterval is the amount for lease 
 extension.Renaming them to leaseRenewPeroid and leaseDuration respectively 
 brings more intuition and readability.
 Besides, leaseDuration should be greater than leaseRenewPeroid to avoid 
 unnecessary master/slave switching.
 The users should be aware of unproper configuration via warning log.

--
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-4348) Consumer not detecting broker restart

2013-02-26 Thread Ronny H. Ringen (JIRA)

Ronny H. Ringen created AMQ-4348:


 Summary: Consumer not detecting broker restart
 Key: AMQ-4348
 URL: https://issues.apache.org/jira/browse/AMQ-4348
 Project: ActiveMQ
  Issue Type: Bug
  Components: Connector
Affects Versions: 5.6.0, 5.5.1
 Environment: Red Hat Enterprise Linux Server 5.8
Reporter: Ronny H. Ringen


This seems to be more or less identical to AMQ-1722

We run the AMQ 5.5.1 broker and our JEE/Spring application runs in Jboss 7.1.1 
and uses the 5.6.0 version of the activemq-all/activemq-core packages.
(also Spring 3.0.5 and Bitronix 2.1.3 for transactions)

I start up the broker, then Jboss, once everything is up, I use mbeans to start 
the application picking matching rows from the DB and creating messages (there 
are 14 queues and associated DLQ queues working in a chain where the consumer 
of one queue is the producer for the next.)

In order to test how it handles errors I shut the broker down, then after some 
time (from a few seconds to a few minutes).

Startup (tried with inactivity monitor due to suggestions in AMQ-1722, it had 
no effect)
[org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS] 
Successfully connected to 
tcp://host:14421?wireFormat.maxInactivityDuration=3

Stopped AMQ
[ActiveMQ Transport: tcp://host/ip:14421] 
[org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS] Transport 
(tcp://ip:14421) failed, reason:  java.io.EOFException, attempting to 
automatically reconnect

the bitronix transactions time out

3 minutes later, and  
org.apache.activemq.SimplePriorityMessageDispatchChannel.closed is still false

start amq again
[ActiveMQ Task-29] [org.apache.activemq.transport.failover.FailoverTransport] 
[JBOSS_AS] Successfully connected to 
tcp://host:14421?wireFormat.maxInactivityDuration=3
[bitronix-recovery-thread] [bitronix.tm.recovery.Recoverer] [JBOSS_AS] 
recoverer is already running, abandoning this recovery request

Then the system handles 55 messages before stopping (assume these are 
prefetched messages), more AMQ restarts makes it handle a variable amount of 
messages (tried 2 more restarts, first one was 13 messages, then 2)

After these the 
org.springframework.jms.listener.DefaultMessageListenerContainer stops 
recieving message events and the SimplePriorityMessageDispatchChannel 
unconsumedMessages in ActiveMQMessageConsumer insists all the queues are of 
size 0, while jconsole shows that they have plenty messages.

--
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: [RESULT][VOTE] Release Apache Apollo 1.6

2013-02-26 Thread Sule BASOL

1+

On 26 Şub 2013, at 00:57, Hiram Chirino hi...@hiramchirino.com wrote:

 Results of the Apache Apollo 1.6 vote: Vote passes with 8 +1 votes.
 
 Thanks to all who reviewed.  I'll push out the artifacts shortly.
 
 -- 
 
 **
 
 *Hiram Chirino*
 
 *Engineering | Red Hat, Inc.*
 
 *hchir...@redhat.com 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] [Updated] (AMQ-4336) SocketException: Connection reset exception occurred in ActiveMQ for Bulk message producer


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

Tamilmaran updated AMQ-4336:


Attachment: (was: Test2-activemq.log)

 SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
 message producer
 --

 Key: AMQ-4336
 URL: https://issues.apache.org/jira/browse/AMQ-4336
 Project: ActiveMQ
  Issue Type: Bug
 Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Priority: Blocker
 Attachments: activemq.log, activemq.xml, SimulatorTC.rar


 I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
 a durable subscriber in server side but not sure about its speed to consume 
 all the messages in same rate as well as the producer.
 But after an hour, 'Connection is already closed' error is logged on producer 
 side.
 On ActiveMQ side, Following error has been logged.
 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
 tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
 org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
 Transport: ssl:///10.2.44.73:59355
 10.2.44.73- Bulk MSG producer IP
 ActiveMQ is using File based cursor and producer control.
 Attached activeMQ config file and producer app(WAPSimulator)

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

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


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

Tamilmaran updated AMQ-4336:


Attachment: Test2-activemq.log

 SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
 message producer
 --

 Key: AMQ-4336
 URL: https://issues.apache.org/jira/browse/AMQ-4336
 Project: ActiveMQ
  Issue Type: Bug
 Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Priority: Blocker
 Attachments: activemq.log, activemq.xml, SimulatorTC.rar


 I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
 a durable subscriber in server side but not sure about its speed to consume 
 all the messages in same rate as well as the producer.
 But after an hour, 'Connection is already closed' error is logged on producer 
 side.
 On ActiveMQ side, Following error has been logged.
 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
 tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
 org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
 Transport: ssl:///10.2.44.73:59355
 10.2.44.73- Bulk MSG producer IP
 ActiveMQ is using File based cursor and producer control.
 Attached activeMQ config file and producer app(WAPSimulator)

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

[jira] [Commented] (AMQ-4348) Consumer not detecting broker restart

2013-02-26 Thread Ronny H. Ringen (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQ-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586967#comment-13586967
 ] 

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

setting maxInactivityDuration=3 makes it (not surprisingly) VERY slow, however, 
the inactivitymonitor does trigger and even after restart of AMQ it connects 
and starts eating messages (though as you would guess, it constantly 
reconnects). 
If I set maxInactivityDuration=30, it acts the same way as with 3, it never 
triggers, even after AMQ has been restartet and no messages are read.

 Consumer not detecting broker restart
 -

 Key: AMQ-4348
 URL: https://issues.apache.org/jira/browse/AMQ-4348
 Project: ActiveMQ
  Issue Type: Bug
  Components: Connector
Affects Versions: 5.5.1, 5.6.0
 Environment: Red Hat Enterprise Linux Server 5.8
Reporter: Ronny H. Ringen

 This seems to be more or less identical to AMQ-1722
 We run the AMQ 5.5.1 broker and our JEE/Spring application runs in Jboss 
 7.1.1 and uses the 5.6.0 version of the activemq-all/activemq-core packages.
 (also Spring 3.0.5 and Bitronix 2.1.3 for transactions)
 I start up the broker, then Jboss, once everything is up, I use mbeans to 
 start the application picking matching rows from the DB and creating messages 
 (there are 14 queues and associated DLQ queues working in a chain where the 
 consumer of one queue is the producer for the next.)
 In order to test how it handles errors I shut the broker down, then after 
 some time (from a few seconds to a few minutes).
 Startup (tried with inactivity monitor due to suggestions in AMQ-1722, it had 
 no effect)
 [org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS] 
 Successfully connected to 
 tcp://host:14421?wireFormat.maxInactivityDuration=3
 Stopped AMQ
 [ActiveMQ Transport: tcp://host/ip:14421] 
 [org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS] 
 Transport (tcp://ip:14421) failed, reason:  java.io.EOFException, 
 attempting to automatically reconnect
 the bitronix transactions time out
 3 minutes later, and  
 org.apache.activemq.SimplePriorityMessageDispatchChannel.closed is still false
 start amq again
 [ActiveMQ Task-29] [org.apache.activemq.transport.failover.FailoverTransport] 
 [JBOSS_AS] Successfully connected to 
 tcp://host:14421?wireFormat.maxInactivityDuration=3
 [bitronix-recovery-thread] [bitronix.tm.recovery.Recoverer] [JBOSS_AS] 
 recoverer is already running, abandoning this recovery request
 Then the system handles 55 messages before stopping (assume these are 
 prefetched messages), more AMQ restarts makes it handle a variable amount of 
 messages (tried 2 more restarts, first one was 13 messages, then 2)
 After these the 
 org.springframework.jms.listener.DefaultMessageListenerContainer stops 
 recieving message events and the SimplePriorityMessageDispatchChannel 
 unconsumedMessages in ActiveMQMessageConsumer insists all the queues are of 
 size 0, while jconsole shows that they have plenty messages.

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

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


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

Tamilmaran updated AMQ-4336:


Attachment: Test2-activemq.log

Two producers(10.2.44.73,10.2.44.80)each push 500msg/4sec to 
server(10.11.146.197)
The second test but with different error logs.
Might be a memory issue?


 SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
 message producer
 --

 Key: AMQ-4336
 URL: https://issues.apache.org/jira/browse/AMQ-4336
 Project: ActiveMQ
  Issue Type: Bug
 Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Priority: Blocker
 Attachments: activemq.log, activemq.xml, SimulatorTC.rar, 
 Test2-activemq.log


 I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
 a durable subscriber in server side but not sure about its speed to consume 
 all the messages in same rate as well as the producer.
 But after an hour, 'Connection is already closed' error is logged on producer 
 side.
 On ActiveMQ side, Following error has been logged.
 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
 tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
 org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
 Transport: ssl:///10.2.44.73:59355
 10.2.44.73- Bulk MSG producer IP
 ActiveMQ is using File based cursor and producer control.
 Attached activeMQ config file and producer app(WAPSimulator)

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

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


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

Tamilmaran commented on AMQ-4336:
-

System configuration (in which ActiveMQ runs):-

Processor:  Intel(R) Xeon(TM) CPU 2.80GHz, 2793 Mhz, 1 Core(s), 2 Logical 
Processor(s)
OS Name:Microsoft Windows Server 2008 R2 Standard
RAM:2GB
System Type:x64-based PC
System Name:INCHN-MCC01


 SocketException: Connection reset exception occurred in ActiveMQ for Bulk 
 message producer
 --

 Key: AMQ-4336
 URL: https://issues.apache.org/jira/browse/AMQ-4336
 Project: ActiveMQ
  Issue Type: Bug
 Environment: ActiveMQ 5.6,NMS,C#
Reporter: Tamilmaran
Priority: Blocker
 Attachments: activemq.log, activemq.xml, SimulatorTC.rar, 
 Test2-activemq.log


 I have a Bulk MSG producer which sends 1000 messages for every 4 seconds. And 
 a durable subscriber in server side but not sure about its speed to consume 
 all the messages in same rate as well as the producer.
 But after an hour, 'Connection is already closed' error is logged on producer 
 side.
 On ActiveMQ side, Following error has been logged.
 2013-02-18 21:45:45,149 | WARN  | Transport Connection to: 
 tcp://10.2.44.73:59355 failed: java.net.SocketException: Connection reset | 
 org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ 
 Transport: ssl:///10.2.44.73:59355
 10.2.44.73- Bulk MSG producer IP
 ActiveMQ is using File based cursor and producer control.
 Attached activeMQ config file and producer app(WAPSimulator)

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

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

2013-02-26 Thread Gary Tully (JIRA)

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

Gary Tully commented on AMQ-4122:
-

thanks for closing the loop.

added LOG warning if lockKeepAlivePeriod lockAcquireSleepInterval

Lease Database Locker failover broken
-

Attachments: activemq-kyle.xml, activemq.xml, activemq.xml,
AMQ4122.patch, mysql.log

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

2013-02-26 Thread Gary Tully (JIRA)


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

Gary Tully commented on AMQ-3353:
-

There is a test case that simulates a very flaky network by randomly closing 
the socket locally. It uses a tcpfaulty://.. transport.
see: org.apache.activemq.usecases.MulticastDiscoveryOnFaultyNetworkTest

Maybe you can use some variant of that to reproduce in a unit test.
When the network cable is unpluged, there is a delay in getting socket feedback 
that depends on the tcp stack settings for timeouts and retries. So from a java 
app perspective, connections that are half closed can appear valid for some 
period. Whatever the case, the broker should be able to deal with it though, 
and once the tcp stack reports the real state of the network, things should 
come back to normal. 

 Durable subscribers on durable topics don't receive messages after network 
 disconnect
 -

 Key: AMQ-3353
 URL: https://issues.apache.org/jira/browse/AMQ-3353
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.3.1, 5.5.0
 Environment: Windows  Linux
 JDK 1.6
Reporter: Syed Faraz Ali
Assignee: Gary Tully
 Fix For: 5.6.0

 Attachments: DurableSubscriberWithNetworkDisconnectTest.java, 
 DurableSubscriberWithNetworkDisconnectTest.java, 
 DurableSubscriberWithNetworkDisconnectTest.java, embedded1.xml, 
 embedded2.xml, example.tar.gz, instructions.txt, standalone1.xml, 
 standalone2.xml, 
 TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
  
 TEST-org.apache.activemq.usecases.DurableSubscriberWithNetworkDisconnectTest.xml,
  test-results.ods


 I've set up a durable topic with the default (persistent) delivery mode on 
 one machine that is publishing a simple text message every 5 seconds. I 
 created a durable subscriber that consumes messages published to the above 
 topic on another machine. I am using broker to broker communication between 
 the two machines.
 I start up the two programs on either machine and see the messages coming 
 through to the subscriber. If I then pull the network cable to disconnect the 
 network between the two machines, wait for a minute and then plug it back in, 
 my subscriber doesn't receive the messages any more. I can see from the 
 output that the publisher is still publishing them (Temporary topics, 
 non-durable queues all continue to sync up in our production environment, it 
 is only the durable topics that don't work after network reconnect)
 If I were to tweak a setting on the publisher's broker (that was introduced 
 only in 5.5.0), suppressDuplicateTopicSubscriptions=false, then the topics 
 work correctly after network reconnect. But this may have other unintended 
 consequences and I was hoping to get a better idea of:
 - is this a known issue ? if so, then are there any specific challenges that 
 have caused it not to be fixed?
 - are other people out there using durable topics and subscribers without a 
 failover option that have run into this problem? What have they done to work 
 around?
 Here is how my subscriber and publisher are set up:
 Topic Publisher (Machine 1)
 publisherConnection = connFactory.createConnection();
 publisherConnection.setClientID( ProducerCliID );
 publisherConnection.start();
 session = publisherConnection.createSession( true, -1 );
 Destination producerTopic = session.createTopic( TEST_TOPIC_NAME );
 producer = session.createProducer( (Topic)producerTopic );
 
 
 
 // On a timer, keep sending this out every 5 seconds
  String text = HELLO  + count++;
 TextMessage msg = session.createTextMessage( text );
 System.out.println( Sending TextMessage =  + msg.getText() 
 );
 producer.send( msg );
 session.commit();
 Subscriber ( Machine 2):
 Connection clientConnection = connFactory.createConnection();
 clientConnection.setClientID(cliID);
 clientConnection.start();
 Session session = clientConnection.createSession( false, 
 Session.AUTO_ACKNOWLEDGE );
 Destination topic = session.createTopic( topicName );
 MessageConsumer subscriber = session.createDurableSubscriber( 
 (Topic)topic, subName );
 TestMessageListener msgListener = new TestMessageListener( 1000 );
 subscriber.setMessageListener( msgListener );
 .
 .
  // TestMessageListener's onMessage method simply outputs the message:
 public void onMessage(Message message)
 {
 if ( message instanceof TextMessage )
 {

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

2013-02-26 Thread RK G (JIRA)


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

RK G closed AMQ-4346.
-

Resolution: Fixed

Duplicate 

 Activemq-5.8.0 Shutdown failing when using NIO + LevelDB
 

 Key: AMQ-4346
 URL: https://issues.apache.org/jira/browse/AMQ-4346
 Project: ActiveMQ
  Issue Type: Bug
Reporter: RK G

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

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

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

2013-02-26 Thread Lucille Wilson (JIRA)

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

Lucille Wilson commented on AMQ-4335:
-

Dear Christian,
I had the 5.6.0 jar in my client application. I switch that out and put in the
activemq-all-5.8.0.jar.
Now I can properly send TextMessage whose payload is over 100MB.

The two changes I had to make were:
1. spell wireFormat correctly in the activemq.xml
2. add the activemq-all-5.8.0.jar to my project.

Thank you, Thank you, Thank you!

However, I have two suggestions for changes, please.
1. When the activemq project is distributed, the conf/activemq.xml spells
wireformat with a small 'f'. Please fix this, because if you use the small 'f'
then the maxFrameSize is not set to a number other than the default. (I tested
this).

So activemq.xml should read:
transportConnectors
!-- DOS protection, limit concurrent connections to 1000 and frame
size to 100MB --
transportConnector name=openwire
uri=tcp://0.0.0.0:61616?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600/
transportConnector name=amqp
uri=amqp://0.0.0.0:5672?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600/
/transportConnectors

2. Please document this a bit better. On this page:
http://activemq.apache.org/configuring-wire-formats.html
Please mention that the default value is NOT max long, but 104857600 (i.e.
100MB), that the value is the number of bytes (not megabytes, gigabytes or any
other thing).

Thank you and thank Timothy for all your help.
Lucille Wilson

Cannot set maxFrameSize greater than 100MB
--

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

Trying 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

[jira] [Closed] (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 closed AMQ-4335.
-

Resolution: Not A Problem

Issue of mixed broker and client versions.  

 Cannot set maxFrameSize greater than 100MB
 --

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


 Trying to send JSON messages greater then 100MB and I receive the error:
 Transport Connection to: tcp://192.168.10.1:55823 failed: 
 java.io.IOException: Frame size of 140 MB larger
  than max allowed 100 MB
 I tried increasing the frame size in 5.8.0 as follows:
 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] [Resolved] (AMQCPP-465) Periodic access violation originating from Openwire::unmarshal

2013-02-26 Thread Scott Weaver (JIRA)

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

Scott Weaver resolved AMQCPP-465.
-

Resolution: Fixed
Fix Version/s: 3.6.0

Ran over the weekend for 39 hours straight until a hang was encountered. More
than just the test was hung so cannot attribuite it to this code. Restarted the
test yesterday without an attached debugger and have been running for over 26
hours straight with no issues. We are confident this access violation has been
fixed. I will mark this JIRA resolved and let you close it once you have a
release containing the fixes. Thanks again for hardening this component. We
have gone from not being able to run extreme tests for more than ten minutes to
at least 39 hours now.

Periodic access violation originating from Openwire::unmarshal
--

Key: AMQCPP-465
URL: https://issues.apache.org/jira/browse/AMQCPP-465
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Openwire
Affects Versions: 3.6.0
Environment: Windows XPSP3 VS2005
Reporter: Scott Weaver
Assignee: Timothy Bish
Fix For: 3.6.0

Attachments: CrashHang_Report__CMStressD.exe__0013114744533.mht,
CrashHang_Report__PID_10568__02212013121958303.mht,
CrashHang_Report__PID_12904__02212013122442266.mht,
CrashHang_Report__PID_13840__02212013122742886.mht,
CrashHang_Report__PID_3816__02212013122319960.mht,
CrashHang_Report__PID_8784__02212013122829943.mht, TcpSocket.cpp, TcpSocket.h

Running a sustained test produced 5 separate access violations all within the
Openwire::unmarshal. It appears only one occurred during termination.
Attaching all 5 dumps.

Jenkins build is still unstable: ActiveMQ-Java7 » ActiveMQ :: Assembly #149

See 
https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$apache-activemq/149/

Jenkins build is back to stable : ActiveMQ-Java7 » ActiveMQ :: HTTP Protocol Support #149

See 
https://builds.apache.org/job/ActiveMQ-Java7/org.apache.activemq$activemq-http/149/

Jenkins build is still unstable: ActiveMQ-Java7 #149

See https://builds.apache.org/job/ActiveMQ-Java7/changes

[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=13587349#comment-13587349
 ] 

Timothy Bish commented on AMQ-4338:
---

I did some profiling and testing today.  So far I couldn't find any real 
issues.  It seems that in the case of these tests the QOS setting just makes 
things ungodly slow due to all the back and forth acking that's going on.  I 
guess its possible there's something amiss in the FuseSource MQTT client 
library but so far I haven't found anything.

 MQTTSSLTest has multiple test cases that fail frequently
 

 Key: AMQ-4338
 URL: https://issues.apache.org/jira/browse/AMQ-4338
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
Reporter: Kevin Earls
Priority: Minor
 Attachments: AMQ-4338A.patch, AMQ-4338.patch


 MQTTSSLTest has multiple different test cases (including 
 testSendAndReceiveExactlyOnce, testSendAndReceiveLargeMessages, 
 testSendAndReceiveMQTT, testSendAtLeastOnceReceiveAtMostOnce, 
 testSendAtLeastOnceReceiveExactlyOnce, testSendJMSReceiveMQTT, 
 testSendMQTTReceiveJMS) which fail fairly frequently because of a hang on the 
 provider.connect() call in initializeConnection() as shown in the stacktrace 
 below. 
 Another problem with this test is it was giving a misleading error when run 
 under Hudson, showing that the test that followed it (MQTTTest) was failing 
 instead.  I think this was because of the way it was using 
 AutoFailTestSupport.  I will attach a patch which removes that and uses 
 timeouts on @Test annotations instead.
 testSendAndReceiveLargeMessages(org.apache.activemq.transport.mqtt.MQTTSSLTest)
   Time elapsed: 30.004 sec   ERROR!
 java.lang.Exception: test timed out after 3 milliseconds
 at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
 at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
 at org.fusesource.mqtt.client.Promise.await(Promise.java:88)
 at 
 org.fusesource.mqtt.client.BlockingConnection.connect(BlockingConnection.java:49)
 at 
 org.apache.activemq.transport.mqtt.FuseMQQTTClientProvider.connect(FuseMQQTTClientProvider.java:39)
 at 
 org.apache.activemq.transport.mqtt.MQTTSSLTest.initializeConnection(MQTTSSLTest.java:60)
 Results :
 Tests in error:
   
 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] [Commented] (AMQ-4341) activemq-broker feature can not be installed when OBR is enabled

2013-02-26 Thread Ioannis Canellos (JIRA)


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

Ioannis Canellos commented on AMQ-4341:
---

Agree

 activemq-broker feature can not be installed when OBR is enabled
 

 Key: AMQ-4341
 URL: https://issues.apache.org/jira/browse/AMQ-4341
 Project: ActiveMQ
  Issue Type: Task
Affects Versions: 5.8.0
Reporter: Gert Vanthienen
Assignee: Gary Tully
 Attachments: AMQ-4341.patch


 While trying to integrate ActiveMQ 5.8.0 into ServiceMix 5.0.0, I bumped into 
 2 problems with the features descriptor on a Karaf-based container that has 
 OBR resolution enabled for the Features service:
 * the activemq-http fragment is referring to a Fragment-Host called 
 {{org.apache.activemq.activemq-core}}, which no longer exists
 * the xbean-spring bundle is marked with {{dependency=true}} but no other 
 bundle is importing any packages from it, so it does not get installed - 
 since {{activemq-karaf}} does need those packages to work properly, the 
 easiest solution is probably to add a proper Import-Package header to that 
 bundle.

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

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

2013-02-26 Thread Ioannis Canellos (JIRA)


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

Ioannis Canellos updated AMQ-4341:
--

Attachment: AMQ-4341-2.patch

I am attaching a second cut of the initial patch.

This patch adopts Gerts suggestion about being explicit on some package 
imports, so that we avoid having issues with the resolver.

The patch also adds some missing depedencies from the features descriptor and 
removes features that have no longer value (activemq-http).

It also adds an itest that checks the activemq-client feature against obr.

Last but not least, it modifies the activemq-osgi headers so that it depends as 
less as possible on dynamic-imports. Added some explict imports and also added 
some optional imports for dependencies that are not used at all by the client.

 activemq-broker feature can not be installed when OBR is enabled
 

 Key: AMQ-4341
 URL: https://issues.apache.org/jira/browse/AMQ-4341
 Project: ActiveMQ
  Issue Type: Task
Affects Versions: 5.8.0
Reporter: Gert Vanthienen
Assignee: Gary Tully
 Attachments: AMQ-4341-2.patch, AMQ-4341.patch


 While trying to integrate ActiveMQ 5.8.0 into ServiceMix 5.0.0, I bumped into 
 2 problems with the features descriptor on a Karaf-based container that has 
 OBR resolution enabled for the Features service:
 * the activemq-http fragment is referring to a Fragment-Host called 
 {{org.apache.activemq.activemq-core}}, which no longer exists
 * the xbean-spring bundle is marked with {{dependency=true}} but no other 
 bundle is importing any packages from it, so it does not get installed - 
 since {{activemq-karaf}} does need those packages to work properly, the 
 easiest solution is probably to add a proper Import-Package header to that 
 bundle.

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

[jira] [Created] (AMQCPP-467) Improve the CMSException types thrown from errors sent back from the broker.

Timothy Bish created AMQCPP-467:
---

 Summary: Improve the CMSException types thrown from errors sent 
back from the broker.
 Key: AMQCPP-467
 URL: https://issues.apache.org/jira/browse/AMQCPP-467
 Project: ActiveMQ C++ Client
  Issue Type: Improvement
  Components: CMS Impl
Affects Versions: 3.5.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 3.6.0


Need to ensure we try to throw a matching CMSException type for the error that 
was sent back from the broker.

--
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-4000) Durable subscription not getting unregistered on networked broker

2013-02-26 Thread Kevin Earls (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQ-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587550#comment-13587550
 ] 

Kevin Earls commented on AMQ-4000:
--

FYI, DurableSubInBrokerNetworkTest.testDurableSubNetwork is currently failing


 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] [Created] (AMQ-4350) SSHTunnelNetworkReconnectTest is failing

2013-02-26 Thread Kevin Earls (JIRA)

Kevin Earls created AMQ-4350:


 Summary: SSHTunnelNetworkReconnectTest is failing
 Key: AMQ-4350
 URL: https://issues.apache.org/jira/browse/AMQ-4350
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
Reporter: Kevin Earls
Priority: Minor


The SSHTunnelNetworkReconnectTest.testWithProducerBrokerRestart is failing.  

Running org.apache.activemq.network.SSHTunnelNetworkReconnectTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.7 sec  
FAILURE!
testWithProducerBrokerRestart(org.apache.activemq.network.SSHTunnelNetworkReconnectTest)
  Time elapsed: 13.534 sec   FAILURE!
junit.framework.AssertionFailedError: The consumer did not arrive.
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at 
org.apache.activemq.network.NetworkReconnectTest.waitForConsumerToArrive(NetworkReconnectTest.java:313)
at 
org.apache.activemq.network.NetworkReconnectTest.testWithProducerBrokerRestart(NetworkReconnectTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



When run on my mac it gets a couple of ssh: connect to host localhost port 22: 
Connection refused right at the beginning of the log, followed by lots of 
TransportDisposedIOException and ConnectionExceptions, as shown below

org.apache.activemq.transport.TransportDisposedIOException: Transport disposed.
at 
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:79)
at 
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
at 
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at 
org.apache.activemq.network.DemandForwardingBridgeSupport$4.run(DemandForwardingBridgeSupport.java:287)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)






java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at 
org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:496)
at 
org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTransport.java:459)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at 
org.apache.activemq.transport.AbstractInactivityMonitor.start(AbstractInactivityMonitor.java:140)
at 
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
at 
org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)
at 
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
at 
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
at 
org.apache.activemq.network.DemandForwardingBridgeSupport.start(DemandForwardingBridgeSupport.java:232)
at 
org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:158)
at 
org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent.start(SimpleDiscoveryAgent.java:89)
at 
org.apache.activemq.network.DiscoveryNetworkConnector.handleStart(DiscoveryNetworkConnector.java:215)
at 
org.apache.activemq.network.NetworkConnector$1.doStart(NetworkConnector.java:59)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at 
org.apache.activemq.network.NetworkConnector.start(NetworkConnector.java:159)
at 
org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerService.java:2401)
at 
org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:650)
at 
org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:617)
at 
org.apache.activemq.broker.BrokerService.start(BrokerService.java:553)
at 
org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60)
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

[jira] [Commented] (AMQ-4350) SSHTunnelNetworkReconnectTest is failing


[ 
https://issues.apache.org/jira/browse/AMQ-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587610#comment-13587610
 ] 

Timothy Bish commented on AMQ-4350:
---

I believe you need an SSH service running in order for this to work. 

 SSHTunnelNetworkReconnectTest is failing
 

 Key: AMQ-4350
 URL: https://issues.apache.org/jira/browse/AMQ-4350
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
Reporter: Kevin Earls
Priority: Minor

 The SSHTunnelNetworkReconnectTest.testWithProducerBrokerRestart is failing.  
 Running org.apache.activemq.network.SSHTunnelNetworkReconnectTest
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.7 sec  
 FAILURE!
 testWithProducerBrokerRestart(org.apache.activemq.network.SSHTunnelNetworkReconnectTest)
   Time elapsed: 13.534 sec   FAILURE!
 junit.framework.AssertionFailedError: The consumer did not arrive.
   at junit.framework.Assert.fail(Assert.java:57)
   at junit.framework.TestCase.fail(TestCase.java:227)
   at 
 org.apache.activemq.network.NetworkReconnectTest.waitForConsumerToArrive(NetworkReconnectTest.java:313)
   at 
 org.apache.activemq.network.NetworkReconnectTest.testWithProducerBrokerRestart(NetworkReconnectTest.java:90)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 When run on my mac it gets a couple of ssh: connect to host localhost port 
 22: Connection refused right at the beginning of the log, followed by lots 
 of TransportDisposedIOException and ConnectionExceptions, as shown below
 org.apache.activemq.transport.TransportDisposedIOException: Transport 
 disposed.
 at 
 org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:79)
 at 
 org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
 at 
 org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
 at 
 org.apache.activemq.network.DemandForwardingBridgeSupport$4.run(DemandForwardingBridgeSupport.java:287)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 java.net.ConnectException: Connection refused
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at 
 java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
 at 
 java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
 at 
 java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
 at java.net.Socket.connect(Socket.java:579)
 at 
 org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:496)
 at 
 org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTransport.java:459)
 at 
 org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
 at 
 org.apache.activemq.transport.AbstractInactivityMonitor.start(AbstractInactivityMonitor.java:140)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.network.DemandForwardingBridgeSupport.start(DemandForwardingBridgeSupport.java:232)
 at 
 org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:158)
 at 
 org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent.start(SimpleDiscoveryAgent.java:89)
 at 
 org.apache.activemq.network.DiscoveryNetworkConnector.handleStart(DiscoveryNetworkConnector.java:215)
 at 
 org.apache.activemq.network.NetworkConnector$1.doStart(NetworkConnector.java:59)
 at 
 org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
 at 
 org.apache.activemq.network.NetworkConnector.start(NetworkConnector.java:159)
 at 
 org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerService.java:2401)
 at 
 org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:650)
 at 
 org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:617)
 at 
 org.apache.activemq.broker.BrokerService.start(BrokerService.java:553)
 at 
 org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60)
 at

[jira] [Resolved] (AMQNET-415) Client with wrong credentials overloads server when using failover

2013-02-26 Thread Jim Gomes (JIRA)

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

Jim Gomes resolved AMQNET-415.
--

Resolution: Fixed

Client with wrong credentials overloads server when using failover
--

Key: AMQNET-415
URL: https://issues.apache.org/jira/browse/AMQNET-415
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ, NMS
Affects Versions: 1.5.6
Environment: ActiveMQ Broker 5.6.0
Reporter: Jim Gomes
Assignee: Jim Gomes
Priority: Minor
Labels: authentication, failover
Fix For: 1.5.7

If the ActiveMQ broker has been secured to enforce login credentials, the NMS
client will continually attempt to authenticate against it if it is using the
failover protocol.
Steps to Reproduce:
--
1. Configure the broker to require login credentials for connections.
2. Configure the NMS client to use failover mode.
3. Configure the NMS client with incorrect login credentials.
4. Attempt to connect the NMS client to the server.
Results:
--
The client reattempts login continuously without backing off, and has a
significant impact on the performance of the server.
Expected:
--
The client should not enter failover, because it never successfully
connected, and it would never expect to connect.
Notes:
--
This was experienced using the OpenWire client, but a similar bug may exist
in the STOMP client's failover code.
The broker may also want to protect itself against this, as this is an easy
attack vector for a DDoS. Just a couple of clients attempting to login with
invalid credentials can dramatically impact the server's performance, not
just the broker.

[jira] [Work stopped] (AMQNET-415) Client with wrong credentials overloads server when using failover

2013-02-26 Thread Jim Gomes (JIRA)

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

Work on AMQNET-415 stopped by Jim Gomes.

Client with wrong credentials overloads server when using failover
--

[jira] [Resolved] (AMQCPP-467) Improve the CMSException types thrown from errors sent back from the broker.


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

Timothy Bish resolved AMQCPP-467.
-

Resolution: Fixed

fixed on trunk

 Improve the CMSException types thrown from errors sent back from the broker.
 

 Key: AMQCPP-467
 URL: https://issues.apache.org/jira/browse/AMQCPP-467
 Project: ActiveMQ C++ Client
  Issue Type: Improvement
  Components: CMS Impl
Affects Versions: 3.5.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 3.6.0


 Need to ensure we try to throw a matching CMSException type for the error 
 that was sent back from the broker.

--
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-4350) SSHTunnelNetworkReconnectTest is failing

2013-02-26 Thread Kevin Earls (JIRA)


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

Kevin Earls closed AMQ-4350.


Resolution: Not A Problem

Of course...time to go update Hudson nodes.


 SSHTunnelNetworkReconnectTest is failing
 

 Key: AMQ-4350
 URL: https://issues.apache.org/jira/browse/AMQ-4350
 Project: ActiveMQ
  Issue Type: Bug
  Components: Test Cases
Reporter: Kevin Earls
Priority: Minor

 The SSHTunnelNetworkReconnectTest.testWithProducerBrokerRestart is failing.  
 Running org.apache.activemq.network.SSHTunnelNetworkReconnectTest
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.7 sec  
 FAILURE!
 testWithProducerBrokerRestart(org.apache.activemq.network.SSHTunnelNetworkReconnectTest)
   Time elapsed: 13.534 sec   FAILURE!
 junit.framework.AssertionFailedError: The consumer did not arrive.
   at junit.framework.Assert.fail(Assert.java:57)
   at junit.framework.TestCase.fail(TestCase.java:227)
   at 
 org.apache.activemq.network.NetworkReconnectTest.waitForConsumerToArrive(NetworkReconnectTest.java:313)
   at 
 org.apache.activemq.network.NetworkReconnectTest.testWithProducerBrokerRestart(NetworkReconnectTest.java:90)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 When run on my mac it gets a couple of ssh: connect to host localhost port 
 22: Connection refused right at the beginning of the log, followed by lots 
 of TransportDisposedIOException and ConnectionExceptions, as shown below
 org.apache.activemq.transport.TransportDisposedIOException: Transport 
 disposed.
 at 
 org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:79)
 at 
 org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
 at 
 org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
 at 
 org.apache.activemq.network.DemandForwardingBridgeSupport$4.run(DemandForwardingBridgeSupport.java:287)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 java.net.ConnectException: Connection refused
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at 
 java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
 at 
 java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
 at 
 java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
 at java.net.Socket.connect(Socket.java:579)
 at 
 org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:496)
 at 
 org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTransport.java:459)
 at 
 org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
 at 
 org.apache.activemq.transport.AbstractInactivityMonitor.start(AbstractInactivityMonitor.java:140)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:58)
 at 
 org.apache.activemq.network.DemandForwardingBridgeSupport.start(DemandForwardingBridgeSupport.java:232)
 at 
 org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:158)
 at 
 org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent.start(SimpleDiscoveryAgent.java:89)
 at 
 org.apache.activemq.network.DiscoveryNetworkConnector.handleStart(DiscoveryNetworkConnector.java:215)
 at 
 org.apache.activemq.network.NetworkConnector$1.doStart(NetworkConnector.java:59)
 at 
 org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
 at 
 org.apache.activemq.network.NetworkConnector.start(NetworkConnector.java:159)
 at 
 org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerService.java:2401)
 at 
 org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:650)
 at 
 org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:617)
 at 
 org.apache.activemq.broker.BrokerService.start(BrokerService.java:553)
 at 
 org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

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

2013-02-26 Thread Gary Tully (JIRA)


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

Gary Tully commented on AMQ-4341:
-

@Ioannis, this looks great. thanks for the patch.
Peeking at org.apache.activemq.karaf.itest.ObrFeatureTest#testBroker that is 
disabled, any idea why that gets a clash of ports on 8181?

on spring-dm in the activemq feature. Do u recall why that is required?

 activemq-broker feature can not be installed when OBR is enabled
 

 Key: AMQ-4341
 URL: https://issues.apache.org/jira/browse/AMQ-4341
 Project: ActiveMQ
  Issue Type: Task
Affects Versions: 5.8.0
Reporter: Gert Vanthienen
Assignee: Gary Tully
 Attachments: AMQ-4341-2.patch, AMQ-4341.patch


 While trying to integrate ActiveMQ 5.8.0 into ServiceMix 5.0.0, I bumped into 
 2 problems with the features descriptor on a Karaf-based container that has 
 OBR resolution enabled for the Features service:
 * the activemq-http fragment is referring to a Fragment-Host called 
 {{org.apache.activemq.activemq-core}}, which no longer exists
 * the xbean-spring bundle is marked with {{dependency=true}} but no other 
 bundle is importing any packages from it, so it does not get installed - 
 since {{activemq-karaf}} does need those packages to work properly, the 
 easiest solution is probably to add a proper Import-Package header to that 
 bundle.

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

Build failed in Jenkins: ActiveMQ-Trunk-Deploy » ActiveMQ :: MQTT Protocol #729

See 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/729/changes

Changes:

[tabish] Apply patch for: https://issues.apache.org/jira/browse/AMQ-4338

--
[INFO] 
[INFO] 
[INFO] Building ActiveMQ :: MQTT Protocol 5.9-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ activemq-mqtt ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-mqtt ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-mqtt ---
[INFO] [WARNING] No proto files found in directory: 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/src/main/proto

[INFO] --- activemq-protobuf:1.1:compile (default) @ activemq-mqtt ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ activemq-mqtt 
---
[debug] execute contextualize
[INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/src/main/filtered-resources
[INFO] Copying 3 resources

[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
activemq-mqtt ---
[INFO] [INFO] Compiling 16 source files to 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/classes

[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
activemq-mqtt ---
[debug] execute contextualize
[INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources

[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
activemq-mqtt ---
[INFO] [INFO] Compiling 6 source files to 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/test-classes

[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
activemq-mqtt ---
[INFO] [INFO] Surefire report directory: 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---

[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ activemq-mqtt ---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ activemq-mqtt ---
[INFO] Building jar: 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/activemq-mqtt-5.9-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ 
activemq-mqtt ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-mqtt ---
[INFO] 
[INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ 
activemq-mqtt ---
Feb 27, 2013 4:42:25 AM hudson.maven.ExecutedMojo init
WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo
[INFO] [INFO] Building jar: 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/activemq-mqtt-5.9-SNAPSHOT-sources.jar

[INFO] --- maven-source-plugin:2.2:jar (attach-sources) @ activemq-mqtt ---
[INFO] 
[INFO] --- maven-javadoc-plugin:2.8.1:jar (attach-javadocs) @ activemq-mqtt ---
[INFO] 
Loading source files for package org.apache.activemq.transport.mqtt...
Constructing Javadoc information...
Standard Doclet version 1.6.0_27
Building tree for all the packages and classes...
Generating 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/apidocs/org/apache/activemq/transport/mqtt//MQTTCodec.html...
Generating 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/apidocs/org/apache/activemq/transport/mqtt//MQTTInactivityMonitor.html...
Generating 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/apidocs/org/apache/activemq/transport/mqtt//MQTTNIOSSLTransport.html...
Generating 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/apidocs/org/apache/activemq/transport/mqtt//MQTTNIOSSLTransportFactory.html...
Generating 
https://builds.apache.org/job/ActiveMQ-Trunk-Deploy/org.apache.activemq$activemq-mqtt/ws/target/apidocs/org/apache/activemq/transport/mqtt//MQTTNIOTransport.html...
Generating

Build failed in Jenkins: ActiveMQ-Trunk-Deploy #729