[jira] [Updated] (AMQ-6275) Error when using ws transport connector

2016-04-29 Thread JIRA 

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

Cristiano José Sulzbach updated AMQ-6275:
-
Description: 
Googled it. Only 20 pages found.

broker.xml:

{code:xml}






{code}

About 43 topics total.
3 publishers, 1 message per second.
Firefox subscribed to 39 topics (websocket).

After few messages received, the following error occurs (Karaf log:tail):

{noformat}

Transport Connection to: ws://x.x.x.x: failed: java.io.IOException: 
Blocking message pending 1 for BLOCKING

{noformat}

  was:
Googled it. Only 20 pages found.

broker.xml:

{code:xml}






{code}

About 43 topics total.
3 publishers, 1 message per second.
Firefox subscribed to 39 topics (websocket).

After few messages received, the following error occurs (Karaf log:tail):

{noformat}
Transport Connection to: ws://x.x.x.x: failed: java.io.IOException: 
Blocking message pending 1 for BLOCKING
{noformat}


> Error when using ws transport connector
> ---
>
> Key: AMQ-6275
> URL: https://issues.apache.org/jira/browse/AMQ-6275
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.2
> Environment: Server:
> Linux 3.16.0-38-generic x86_64
> Karaf 4.0.5
> Java SDK 1.8.0_91-b14
> Client:
> Linux 3.16.0-38-generic x86_64
> Firefox 45.0.2
> Eclipse Paho JavaScript Client 
> (https://raw.githubusercontent.com/eclipse/paho.mqtt.javascript/master/src/mqttws31.js)
> Also tested with http://www.hivemq.com/demos/websocket-client/
>Reporter: Cristiano José Sulzbach
>  Labels: karaf, websocket
>
> Googled it. Only 20 pages found.
> broker.xml:
> {code:xml}
> 
>   
>uri="tcp://0.0.0.0:61616?maximumConnections=1000wireFormat.maxFrameSize=104857600"
>  />
>   
>   
> 
> {code}
> About 43 topics total.
> 3 publishers, 1 message per second.
> Firefox subscribed to 39 topics (websocket).
> After few messages received, the following error occurs (Karaf log:tail):
> {noformat}
> Transport Connection to: ws://x.x.x.x: failed: java.io.IOException: 
> Blocking message pending 1 for BLOCKING
> {noformat}



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

[jira] [Created] (AMQ-6275) Error when using ws transport connector

2016-04-29 Thread JIRA 
Cristiano José Sulzbach created AMQ-6275:


 Summary: Error when using ws transport connector
 Key: AMQ-6275
 URL: https://issues.apache.org/jira/browse/AMQ-6275
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.13.2
 Environment: Server:
Linux 3.16.0-38-generic x86_64
Karaf 4.0.5
Java SDK 1.8.0_91-b14

Client:
Linux 3.16.0-38-generic x86_64
Firefox 45.0.2
Eclipse Paho JavaScript Client 
(https://raw.githubusercontent.com/eclipse/paho.mqtt.javascript/master/src/mqttws31.js)

Also tested with http://www.hivemq.com/demos/websocket-client/


Reporter: Cristiano José Sulzbach


Googled it. Only 20 pages found.

broker.xml:

{code:xml}






{code}

About 43 topics total.
3 publishers, 1 message per second.
Firefox subscribed to 39 topics (websocket).

After few messages received, the following error occurs (Karaf log:tail):

{noformat}
Transport Connection to: ws://x.x.x.x: failed: java.io.IOException: 
Blocking message pending 1 for BLOCKING
{noformat}



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

[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header

2016-04-29 Thread Quinn Stevenson (JIRA) 

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

Quinn Stevenson commented on AMQ-6274:
--

You can assign this to me - I've just about got a PR ready for it.

> Add option to composite destinations to set originalMessage header
> --
>
> Key: AMQ-6274
> URL: https://issues.apache.org/jira/browse/AMQ-6274
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.13.2
>Reporter: Quinn Stevenson
>Priority: Minor
>
> Composite Destinations are a great way to wiretap messages, but the resulting 
> messages don't have any information in them about where they originally came 
> from.
> I'm proposing to add an option to composite destinations ( addHeaders ) that 
> will enable the addition of the originalDestination header to the messages.  
> The option will be disabled by default to preserve existing behavior by 
> default.



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

[jira] [Created] (AMQ-6274) Add option to composite destinations to set originalMessage header

2016-04-29 Thread Quinn Stevenson (JIRA) 
Quinn Stevenson created AMQ-6274:


 Summary: Add option to composite destinations to set 
originalMessage header
 Key: AMQ-6274
 URL: https://issues.apache.org/jira/browse/AMQ-6274
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.13.2
Reporter: Quinn Stevenson
Priority: Minor


Composite Destinations are a great way to wiretap messages, but the resulting 
messages don't have any information in them about where they originally came 
from.

I'm proposing to add an option to composite destinations ( addHeaders ) that 
will enable the addition of the originalDestination header to the messages.  
The option will be disabled by default to preserve existing behavior by default.



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

[jira] [Commented] (ARTEMIS-245) Change resource adapter to work with Tomee

2016-04-29 Thread Jonathan S. Fisher (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264341#comment-15264341
 ] 

Jonathan S. Fisher commented on ARTEMIS-245:


I'm fairly certain from the discussions last year, it's because 
ActiveMQRASession is a concrete final class with no interface, and it allows 
TomEE to cleanup resources that might be held by the developer.


I'm trying a much more brutal method, which is to make ActiveMQRASession an 
interface, have a ActiveMQRASessionDefault concrete implementation. The 
consequence of this is you can't have protected methods on an interface, so 
things like _lock()_ and _unlock()_ will have to be public methods.

> Change resource adapter to work with Tomee
> --
>
> Key: ARTEMIS-245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-245
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
> Attachments: patch.txt
>
>
> It seems that Tomee requires a JMS interface to be returned. We should try 
> changing the RA to be compatible with it.



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

[jira] [Commented] (ARTEMIS-510) Do not create server-side queue from client when creating JMS producer

2016-04-29 Thread Justin Bertram (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264335#comment-15264335
 ] 

Justin Bertram commented on ARTEMIS-510:


The changes in 95b6328993b8215262cb49e0bc1e5999d3537e12 missed the code in 
org.apache.activemq.artemis.jms.client.ActiveMQSession#createProducer where the 
client creates a server-side queue when a JMS producer is created for a 
non-existent queue when auto-queue-creation is enabled.  The server should 
create the queue when it routes the messages instead.  This is not only more 
efficient, but it also takes care of creating the JMS related MBean for 
managing the queue.

> Do not create server-side queue from client when creating JMS producer
> --
>
> Key: ARTEMIS-510
> URL: https://issues.apache.org/jira/browse/ARTEMIS-510
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Updated] (ARTEMIS-510) Do not create server-side queue from client when creating JMS producer

2016-04-29 Thread Justin Bertram (JIRA) 

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

Justin Bertram updated ARTEMIS-510:
---
Fix Version/s: 1.3.0

> Do not create server-side queue from client when creating JMS producer
> --
>
> Key: ARTEMIS-510
> URL: https://issues.apache.org/jira/browse/ARTEMIS-510
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Created] (ARTEMIS-510) Do not create server-side queue from client when creating JMS producer

2016-04-29 Thread Justin Bertram (JIRA) 
Justin Bertram created ARTEMIS-510:
--

 Summary: Do not create server-side queue from client when creating 
JMS producer
 Key: ARTEMIS-510
 URL: https://issues.apache.org/jira/browse/ARTEMIS-510
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Justin Bertram
Assignee: Justin Bertram






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

[jira] [Commented] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE

2016-04-29 Thread Timothy Bish (JIRA) 

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

Timothy Bish commented on AMQ-6273:
---

You should write a unit test to demonstrate the issue

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if 
> ReconnectionPolicy.maxReconnectAttempts/maxInitialConnectAttempts == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Summary: ReconnectionPolicy.getNextDelay(int attempt) always returns zero 
when maxReconnectAttempts/maxInitialConnectAttempts == 
ReconnectionPolicy.INFINITE  (was: ReconnectionPolicy.getNextDelay(int attempt) 
always returns zero when maxSendRetries == ReconnectionPolicy.INFINITE)

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Description: 
The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
contains a defect within method *private void doInitializeConnection(boolean 
local) throws Exception* that causes the *attempt* variable to
 always retain a value of zero if 
ReconnectionPolicy.maxReconnectAttempts/maxInitialConnectAttempts == 
ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
iterations)

This indirectly prevents the connector from using any of the following 
ReconnectionPolicy configuration properties:

private long initialReconnectDelay = 1000L;
private long maximumReconnectDelay = 3;
private boolean useExponentialBackOff = false;
private double backOffMultiplier = 2.0;

  was:
The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
contains a defect within method *private void doInitializeConnection(boolean 
local) throws Exception* that causes the *attempt* variable to
 always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
iterations)

This indirectly prevents the connector from using any of the following 
ReconnectionPolicy configuration properties:

private long initialReconnectDelay = 1000L;
private long maximumReconnectDelay = 3;
private boolean useExponentialBackOff = false;
private double backOffMultiplier = 2.0;


> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxReconnectAttempts/maxInitialConnectAttempts == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if 
> ReconnectionPolicy.maxReconnectAttempts/maxInitialConnectAttempts == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Assigned] (AMQ-5603) Consider preallocation of journal files in batch increments

2016-04-29 Thread Gary Tully (JIRA) 

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

Gary Tully reassigned AMQ-5603:
---

Assignee: Gary Tully

> Consider preallocation of journal files in batch increments
> ---
>
> Key: AMQ-5603
> URL: https://issues.apache.org/jira/browse/AMQ-5603
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Message Store
>Reporter: Christian Posta
>Assignee: Gary Tully
>Priority: Minor
>  Labels: kahaDB, perfomance
>
> Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the 
> only scope is for entire journal file. The [potential] issue with that is if 
> user configures large journal file sizes, we can end up stalling writes 
> during log rotation because of the allocation process. There are two ways to 
> do the allocation, configurable to do it in userspace, or defer to kernel 
> space, but nevertheless it would be good to avoid this issue altogether by 
> preallocating in small batch sizes regardless of the journal max file size.



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

[jira] [Updated] (AMQ-5603) Consider preallocation of journal files in batch increments

2016-04-29 Thread Gary Tully (JIRA) 

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

Gary Tully updated AMQ-5603:

Issue Type: Improvement  (was: New Feature)

> Consider preallocation of journal files in batch increments
> ---
>
> Key: AMQ-5603
> URL: https://issues.apache.org/jira/browse/AMQ-5603
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Message Store
>Reporter: Christian Posta
>Priority: Minor
>  Labels: kahaDB, perfomance
>
> Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the 
> only scope is for entire journal file. The [potential] issue with that is if 
> user configures large journal file sizes, we can end up stalling writes 
> during log rotation because of the allocation process. There are two ways to 
> do the allocation, configurable to do it in userspace, or defer to kernel 
> space, but nevertheless it would be good to avoid this issue altogether by 
> preallocating in small batch sizes regardless of the journal max file size.



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

[jira] [Resolved] (AMQ-5578) preallocate journal files

2016-04-29 Thread Gary Tully (JIRA) 

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

Gary Tully resolved AMQ-5578.
-
Resolution: Fixed

the test suite looks good without the metadata sync.

https://issues.apache.org/jira/browse/AMQ-5603 introduces a 
preallocationScope=none that can disable. With the addition of async it is nice 
to be able to compare.

> preallocate journal files
> -
>
> Key: AMQ-5578
> URL: https://issues.apache.org/jira/browse/AMQ-5578
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Message Store
>Affects Versions: 5.11.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: journal, kahaDB, perfomance
> Fix For: 5.14.0
>
>
> Our journals are append only, however we use the size to track journal 
> rollover on recovery and replay. We can improve performance if we never 
> update the size on disk and preallocate on creation.
> Rework journal logic to ensure size is never updated. This will allow the 
> configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to 
> be the default.



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxSendRetries == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Priority: Minor  (was: Major)

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxSendRetries == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>Priority: Minor
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxSendRetries == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Affects Version/s: NEEDS_REVIEW

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxSendRetries == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxSendRetries == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Priority: Major  (was: Minor)

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxSendRetries == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: NEEDS_REVIEW, 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Updated] (AMQ-6273) ReconnectionPolicy.getNextDelay(int attempt) always returns zero when maxSendRetries == ReconnectionPolicy.INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 

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

Ben Nisbet updated AMQ-6273:

Flags: Important
Affects Version/s: (was: 5.10.2)
   5.12.1
  Environment: WebLogic 10.3.6, HotSpot JDK 1.7  (was: WebLogic 10.3.6, 
JRockit JDK 1.6)
Fix Version/s: (was: 5.12.1)
   (was: 5.13.0)
  Description: 
The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
contains a defect within method *private void doInitializeConnection(boolean 
local) throws Exception* that causes the *attempt* variable to
 always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
iterations)

This indirectly prevents the connector from using any of the following 
ReconnectionPolicy configuration properties:

private long initialReconnectDelay = 1000L;
private long maximumReconnectDelay = 3;
private boolean useExponentialBackOff = false;
private double backOffMultiplier = 2.0;

  was:
When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector 
bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 
to result in message loss if the connection to destination server is 
unreliable. (messages that are not delivered to destination within 
maxSendRetries are still acknowledged as having been consumed by processing of 
later messages)

Is it possible for the 
org.apache.activemq.network.jms.DestinationBridge.onMessage() implementation to 
interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity?






  Component/s: (was: Broker)
   Connector
   Issue Type: Bug  (was: Improvement)
  Summary: ReconnectionPolicy.getNextDelay(int attempt) always 
returns zero when maxSendRetries == ReconnectionPolicy.INFINITE  (was: 
ReconnectionPolicy,getNextDelay(int attempt) always returns zero when 
maxSendRetries set to INFINITE)

> ReconnectionPolicy.getNextDelay(int attempt) always returns zero when 
> maxSendRetries == ReconnectionPolicy.INFINITE
> ---
>
> Key: AMQ-6273
> URL: https://issues.apache.org/jira/browse/AMQ-6273
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.12.1
> Environment: WebLogic 10.3.6, HotSpot JDK 1.7
>Reporter: Ben Nisbet
>
> The v.5.12.1 release of class org.apache.activemq.network.jms.JmsConnector 
> contains a defect within method *private void doInitializeConnection(boolean 
> local) throws Exception* that causes the *attempt* variable to
>  always retain a value of zero if ReconnectionPolicy.maxSendRetries == 
> ReconnectionPolicy.INFINITE. (irrespective of the actual number of loop 
> iterations)
> This indirectly prevents the connector from using any of the following 
> ReconnectionPolicy configuration properties:
> private long initialReconnectDelay = 1000L;
> private long maximumReconnectDelay = 3;
> private boolean useExponentialBackOff = false;
> private double backOffMultiplier = 2.0;



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

[jira] [Commented] (AMQ-5603) Consider preallocation of journal files in batch increments

2016-04-29 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-5603:
-

[~ceposta] I extended scope to have a preallocate_async option - so that we 
fire a job to preallocate the next data file when we rotate. This seems to 
reduce latency jitter on publish but it needs validation on real hardware.
On the kernel_copy strategy - I did not see any point to deleting/recreating 
the template file so that is changed. Can you peek at that?
In an effort to keep this safe, the sync is very explicit in journal. The whole 
class was synchronized which had to change to allow contention on the 
nextWriteId between the appender and the async task.

> Consider preallocation of journal files in batch increments
> ---
>
> Key: AMQ-5603
> URL: https://issues.apache.org/jira/browse/AMQ-5603
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Reporter: Christian Posta
>Priority: Minor
>  Labels: kahaDB, perfomance
>
> Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the 
> only scope is for entire journal file. The [potential] issue with that is if 
> user configures large journal file sizes, we can end up stalling writes 
> during log rotation because of the allocation process. There are two ways to 
> do the allocation, configurable to do it in userspace, or defer to kernel 
> space, but nevertheless it would be good to avoid this issue altogether by 
> preallocating in small batch sizes regardless of the journal max file size.



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

[jira] [Commented] (AMQ-5603) Consider preallocation of journal files in batch increments

2016-04-29 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on AMQ-5603:
--

Commit 62bdbb0db5dc4354f0e00fd5259b3db53eb1432d in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=62bdbb0 ]

https://issues.apache.org/jira/browse/AMQ-5603 - add 
preallocationScope=full_journal_async that will preallocate a journal in 
advance or use to avoid latency jitter on journal rotation. Added none option 
to disable preallocation


> Consider preallocation of journal files in batch increments
> ---
>
> Key: AMQ-5603
> URL: https://issues.apache.org/jira/browse/AMQ-5603
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Reporter: Christian Posta
>Priority: Minor
>  Labels: kahaDB, perfomance
>
> Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the 
> only scope is for entire journal file. The [potential] issue with that is if 
> user configures large journal file sizes, we can end up stalling writes 
> during log rotation because of the allocation process. There are two ways to 
> do the allocation, configurable to do it in userspace, or defer to kernel 
> space, but nevertheless it would be good to avoid this issue altogether by 
> preallocating in small batch sizes regardless of the journal max file size.



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

[jira] [Created] (AMQ-6273) ReconnectionPolicy,getNextDelay(int attempt) always returns zero when maxSendRetries set to INFINITE

2016-04-29 Thread Ben Nisbet (JIRA) 
Ben Nisbet created AMQ-6273:
---

 Summary: ReconnectionPolicy,getNextDelay(int attempt) always 
returns zero when maxSendRetries set to INFINITE
 Key: AMQ-6273
 URL: https://issues.apache.org/jira/browse/AMQ-6273
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 5.10.2
 Environment: WebLogic 10.3.6, JRockit JDK 1.6
Reporter: Ben Nisbet
 Fix For: 5.12.1, 5.13.0


When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector 
bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 
to result in message loss if the connection to destination server is 
unreliable. (messages that are not delivered to destination within 
maxSendRetries are still acknowledged as having been consumed by processing of 
later messages)

Is it possible for the 
org.apache.activemq.network.jms.DestinationBridge.onMessage() implementation to 
interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity?








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

[jira] [Commented] (ARTEMIS-397) MQTT protocol - connection TTL = keepAliveTimeSeconds * 750

2016-04-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264223#comment-15264223
 ] 

ASF GitHub Bot commented on ARTEMIS-397:


GitHub user incarosegit opened a pull request:

https://github.com/apache/activemq-artemis/pull/497

Change keep alive ratio to 1.5 from 0.75

Fixes: ARTEMIS-397

From mqtt specs:

“If the Keep Alive value is non-zero and the Server does not receive a
Control Packet from the Client within one and a half times the Keep
Alive time period, it MUST disconnect the Network Connection to the
Client as if the network had failed [MQTT-3.1.2-24]. “

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/incarosegit/activemq-artemis master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/497.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #497


commit 6bdad3db2a8e19069f7d1d5b44c97ceb0fc05b92
Author: Diego Bes 
Date:   2016-04-29T15:43:25Z

Change keep alive ratio to 1.5 from 0.75

Fixes: ARTEMIS-397

From mqtt specs:

“If the Keep Alive value is non-zero and the Server does not receive a
Control Packet from the Client within one and a half times the Keep
Alive time period, it MUST disconnect the Network Connection to the
Client as if the network had failed [MQTT-3.1.2-24]. “




> MQTT protocol - connection TTL = keepAliveTimeSeconds * 750
> ---
>
> Key: ARTEMIS-397
> URL: https://issues.apache.org/jira/browse/ARTEMIS-397
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: hiawui
>
> For MQTT protocol, the connection TTL is equal to keepAliveTimeSeconds * 750, 
> causes connections always disconnected by timeout. Is it a bug? or why?
> {code:title=MQTTProtocolHandler.java:159|borderStyle=solid}
>void handleConnect(MqttConnectMessage connect, ChannelHandlerContext ctx) 
> throws Exception {
>   this.ctx = ctx;
>   connectionEntry.ttl = connect.variableHeader().keepAliveTimeSeconds() * 
> 750; // this line!!!, why not multiply by larger than 1000?
>   String clientId = connect.payload().clientIdentifier();
>   session.getConnectionManager().connect(clientId, 
> connect.payload().userName(), connect.payload().password(), 
> connect.variableHeader().isWillFlag(), connect.payload().willMessage(), 
> connect.payload().willTopic(), connect.variableHeader().isWillRetain(), 
> connect.variableHeader().willQos(), 
> connect.variableHeader().isCleanSession());
>}
> {code}



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

[jira] [Commented] (AMQ-6118) ActiveMQ SSL CRL Checking via OCSP

2016-04-29 Thread Marko Jovanovic (JIRA) 

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

Marko Jovanovic commented on AMQ-6118:
--

Wow, thank you! Dejan you're the man. 
Could you introduce me into the Windows Distribution? I'm confused setting the 
ACTIVEMQ_SSL_OPTS. Where do I have to set all the configurations in Windows 
Distribution?

Thanks for reply.
much regards

> ActiveMQ SSL CRL Checking via OCSP
> --
>
> Key: AMQ-6118
> URL: https://issues.apache.org/jira/browse/AMQ-6118
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.12.1
> Environment: Windows Server 2012R2 with ActiveMQ Windows Distribution
>Reporter: Marko Jovanovic
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
> Attachments: jvm_args.png
>
>
> For some unknown reason, the CRL Check via OCSP isn't working in Windows 
> ActiveMQ 5.12.1
> After reviewing the Linux distribution of Activemq there was a configuration 
> line found in the file bin/env.
> The Config in Linux Distribution looked like:
> # Set additional JSE arguments
> #ACTIVEMQ_SSL_OPTS="-Dcom.sun.security.enableCRLDP=true -Docsp.enable=true 
> -Docsp.responderURL=http://ocsp.example.net:80;
> Where to set it in Windows file distribution? 
> Tried to set it in activemq file but no success. I couldn't see any request 
> going to the responder URL which I configured.
> Think there is a general Problem with the code concerning OCSP functionality.



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

[jira] [Commented] (AMQ-6135) ActiveMQ HTTP module should support Openwire serialisation

2016-04-29 Thread Przemek Bruski (JIRA) 

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

Przemek Bruski commented on AMQ-6135:
-

Any news?

> ActiveMQ HTTP module should support Openwire serialisation
> --
>
> Key: AMQ-6135
> URL: https://issues.apache.org/jira/browse/AMQ-6135
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Przemek Bruski
>




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

[jira] [Created] (AMQ-6272) Gmail Phone Number for Technical support USA CANADA

2016-04-29 Thread Patrick Same (JIRA) 
Patrick Same created AMQ-6272:
-

 Summary: Gmail Phone Number for Technical support USA CANADA
 Key: AMQ-6272
 URL: https://issues.apache.org/jira/browse/AMQ-6272
 Project: ActiveMQ
  Issue Type: Bug
  Components: CMS (C++ client)
Affects Versions: 5.12.2
 Environment: Windows 7
Reporter: Patrick Same
 Fix For: 5.x


There are many reasons to consider outsourcing your organization's email versus 
keeping it in-house. Not just can outsourcing save time and money, it also 
offers greater security and reliability. For both small business owners and IT 
managers, moving to an outsourced solution places the responsibility of 
maintaining and managing the email infrastructure in the hands of a trusted 
email hosting partner. And as email volumes increase, maintaining these 
archives becomes more critical to handle and access on regular basis. Many 
businesses initially assemble or purchase an in-house mail server in the 
interest of protecting their correspondence. However, unless the server is 
properly maintained, an in-house server may offer less security than a managed 
outsourced solution. At the very least garbage mail, viruses and attacks may 
unexpectedly crush your email services to a halt. In a disaster scenario, an 
in-house server hard drive failure could result in a total loss of data which 
can be reverting by Gmail customer service 1-866-293-8400.





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

[jira] [Commented] (AMQ-5605) High CPU load when using failover transport in network connector

2016-04-29 Thread ruffp (JIRA) 

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

ruffp commented on AMQ-5605:


Does this bug affect the version 5.10.2 of ActiveMQ? Because we have a similar 
problem qith 100% CPU usage and nothing special in logs.
Our ActiveMQ was working fine until we introduce the Network Connector with 
{{masterslave:(tcp://host1, tcp://host2)}}

> High CPU load when using failover transport in network connector
> 
>
> Key: AMQ-5605
> URL: https://issues.apache.org/jira/browse/AMQ-5605
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: Ubuntu 14.04, SuSE Enterprise 11.3
>Reporter: Lars Neumann
>  Labels: failover
> Fix For: 5.12.0, 5.11.3
>
>
> I've got a configuration with two master/slave setups consisting of 3 
> ActiveMQ instances each. They are deployed on three servers, with one 
> ActiveMQ instance from each master/slave setup on every server. They are 
> using the leveldb and zookeeper. Everything works fine.
> Now I've got the strange behaviour that when I add a network connector to 
> each ActiveMQ instance like this:
> {code}
> networkConnector name="toMasterSlave02" dynamicOnly="true" 
> uri="masterslave:(tcp://host1:61617,tcp://host2:61617,tcp://host3:61617)"
> {code}
> When you now restart the master of the master/slave setup that is targeted by 
> the above network connector the cpu load on the current master goes and stays 
> up at 100%, i.e. it uses one CPU per configured transportConnector.
> Now the explanation, mostly copied from 
> http://activemq.2283324.n4.nabble.com/High-CPU-load-with-network-connector-failover-transport-tp4691798.html
> {quote}
> When one of the brokers is restarted, the other broker uses ~400% CPU. The 
> cause is the FailoverTransport reconnectTask spinning, and nothing is 
> stopping the task.
> Reverting this fix made for AMQ-5315, while it does reintroduce the 
> NullPointerException, does handle failover properly without spinning:
> https://git1-us-west.apache.org/repos/asf/activemq/repo?p=activemq.git;a=commitdiff;h=c391321d1b5b59542d847717654b0d4dba54cf2f
>  
> 
> The reason it works after reverting that change is the NullPointerException 
> is caught, -> serviceLocalException() -> 
> ServiceSupport.dispose(getControllingService()); with the fix made in 
> AMQ-5315, the dispose() call is never made. 
> {quote}
> Sorry, but I've got no clue how to provide a unit test for this. Maybe 
> someone else can help.



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