[jira] [Commented] (ARTEMIS-751) Cleanup Client classes from AMQP Implementation

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-751:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/794
  
I had the whole testsuite on running on this. no regressions.


> Cleanup Client classes from AMQP Implementation
> ---
>
> Key: ARTEMIS-751
> URL: https://issues.apache.org/jira/browse/ARTEMIS-751
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.0
>
>
> When I created artemis-proton-plug and the current implementation on 
> artemis-amqp-protocol, the qpid-jms client was in its beginning and I had 
> some difficulties on testing raw clients against the server, so I had some 
> classes around to perform several client->server tasks.
> I had to write some abstract model to support both client and server...
> I also wrote it independently to be reused in other servers. 
> Since there's no more need for the client part, I decided to do some 
> simplifications over the class model.
> - removing the artemis-proton-plug
> - removng lots of interfaces that only have a single implementation
>   * in a try to make the code easier to understand for developers working on 
> it at the first time.
> No semantics will be changed as part of this task.



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


[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

2016-09-23 Thread Quinn Stevenson (JIRA)

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

Quinn Stevenson commented on ARTEMIS-737:
-

@clebertsuconic  -I had an idea - I noticed that none of the examples have a 
"unit test".  I know you can run them with some the maven infrastructure that 
is available in the examples, but I thought it would be nice to have a unit 
test for an individual example.  So I updated the "Bridge" example 
(examples/features/standard/bridge) and added a unit test using the 
EmbeddedJMSResource - can you give it a look?

Note that I had to change the broker.xml files to get rid of a security 
exception I was seeing with the test - not really sure what's going on there.  
But if you like the idea, I could update a few more of the examples to include 
this type of unit test.

> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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


[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes commented on ARTEMIS-750:
---

Yes. If I modify the {{artemis-service.xml}} file to use my JAVA_HOME instance, 
it will work.  I changed the following line:

{code}
   %JAVA_HOME%\bin\java
{code}

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Comment Edited] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes edited comment on ARTEMIS-750 at 9/23/16 10:44 PM:
-

This could be my environment being messed up.  When I manually run that 
command-line from the artemis-service.log, I get a Registry key value error:

{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}

This is a little strange, since Artemis will run just fine. Let me fix my 
environment settings first.

Update: I think I see the difference.  If I explicitly use my JAVA_HOME defined 
instance (which is Java 1.8), then it will work.  So, I run the following 
command-line (assuming all of the parameters from the log output on the command 
line):

{noformat}
"%java_home%\bin\java" "-Xbootclasspath/a:C:\Proga"
{noformat}

and it will run.


was (Author: jgomes):
This could be my environment being messed up.  When I manually run that 
command-line from the artemis-service.log, I get a Registry key value error:

{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}

This is a little strange, since Artemis will run just fine. Let me fix my 
environment settings first.

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes commented on ARTEMIS-750:
---

This could be my environment being messed up.  When I manually run that 
command-line from the artemis-service.log, I get a Registry key value error:

{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}

This is a little strange, since Artemis will run just fine. Let me fix my 
environment settings first.

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Comment Edited] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes edited comment on ARTEMIS-750 at 9/23/16 10:30 PM:
-

I can give it a try. I'll look at that file to begin with.  Any pointers on 
where to look are appreciated, as I'm not familiar with the service wrapper 
strategy that Artemis is using.


was (Author: jgomes):
I can give it a try. I'll look at that file to begin with.  Any pointers how 
where to look are appreciated, as I'm not familiar with the service wrapper 
strategy that Artemis is using.

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Created] (ARTEMIS-751) Cleanup Client classes from AMQP Implementation

2016-09-23 Thread clebert suconic (JIRA)
clebert suconic created ARTEMIS-751:
---

 Summary: Cleanup Client classes from AMQP Implementation
 Key: ARTEMIS-751
 URL: https://issues.apache.org/jira/browse/ARTEMIS-751
 Project: ActiveMQ Artemis
  Issue Type: Task
Reporter: clebert suconic
Assignee: clebert suconic


When I created artemis-proton-plug and the current implementation on 
artemis-amqp-protocol, the qpid-jms client was in its beginning and I had some 
difficulties on testing raw clients against the server, so I had some classes 
around to perform several client->server tasks.

I had to write some abstract model to support both client and server...

I also wrote it independently to be reused in other servers. 


Since there's no more need for the client part, I decided to do some 
simplifications over the class model.


- removing the artemis-proton-plug
- removng lots of interfaces that only have a single implementation
  * in a try to make the code easier to understand for developers working on it 
at the first time.



No semantics will be changed as part of this task.



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


[jira] [Updated] (ARTEMIS-751) Cleanup Client classes from AMQP Implementation

2016-09-23 Thread clebert suconic (JIRA)

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

clebert suconic updated ARTEMIS-751:

Affects Version/s: 1.4.0
Fix Version/s: 1.5.0

> Cleanup Client classes from AMQP Implementation
> ---
>
> Key: ARTEMIS-751
> URL: https://issues.apache.org/jira/browse/ARTEMIS-751
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.0
>
>
> When I created artemis-proton-plug and the current implementation on 
> artemis-amqp-protocol, the qpid-jms client was in its beginning and I had 
> some difficulties on testing raw clients against the server, so I had some 
> classes around to perform several client->server tasks.
> I had to write some abstract model to support both client and server...
> I also wrote it independently to be reused in other servers. 
> Since there's no more need for the client part, I decided to do some 
> simplifications over the class model.
> - removing the artemis-proton-plug
> - removng lots of interfaces that only have a single implementation
>   * in a try to make the code easier to understand for developers working on 
> it at the first time.
> No semantics will be changed as part of this task.



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


[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Justin Bertram (JIRA)

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

Justin Bertram commented on ARTEMIS-750:


Any chance you can debug this?  It's probably a minor error in the 
artemis-service.xml or something.

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Commented] (ARTEMIS-749) Version Number Does Not Display for Windows Service

2016-09-23 Thread Justin Bertram (JIRA)

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

Justin Bertram commented on ARTEMIS-749:


The Artemis version number is not intended to be part of the service name.  
Here is the relevant bit from the artemis-service.xml file before the values 
are replaced during the instance-creation process:

{noformat}
   artemis-${artemis.instance.name}-${host}
   ActiveMQ Artemis: ${artemis.instance.name} @ ${host}
{noformat}

The $\{artemis.instance.name\} is the last part of the directory argument 
provided to the {{create}} command.

The $\{host\} is the {{\-\-host}} option passed to the {{create}} command.  If 
no {{--host}} value is passed then {{0.0.0.0}} is used.

After the instance is created you can customize these as you see fit if 
necessary.

> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
>  Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number 
> correctly.  Instead, it displays 0.0.0.0.  Please see attached screenshot 
> showing the issue.



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


[jira] [Resolved] (ARTEMIS-749) Version Number Does Not Display for Windows Service

2016-09-23 Thread Justin Bertram (JIRA)

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

Justin Bertram resolved ARTEMIS-749.

Resolution: Not A Problem

> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
>  Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number 
> correctly.  Instead, it displays 0.0.0.0.  Please see attached screenshot 
> showing the issue.



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


[jira] [Created] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)
Jim Gomes created ARTEMIS-750:
-

 Summary: Artemis Windows Service Fails to Start
 Key: ARTEMIS-750
 URL: https://issues.apache.org/jira/browse/ARTEMIS-750
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.4.0
 Environment: Windows 10 Anniversary Edition, 64-bit
Reporter: Jim Gomes
Priority: Blocker
 Fix For: 1.5.0


After installing Artemis as a service successfully using the following 
command-line:

{{artemis-service install}}

the service returns an error when I try to start it.

# Go to the Services control panel
# select the Artemis service entry
# right click to bring up the context menu
# click the Start menu item.

It looks like it tries to start, but then an error dialog is displayed (see 
attached image).  When the service error log is checked, no error is logged. 
The following is logged:

{noformat}
2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
-XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
-Xmx1024M -classpath "C:\Program 
Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
"-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
-Dartemis.instance=C:\ProgramData\Apache\AMQ 
-Djava.util.logging.manager=org.jboss.logmanager.LogManager 
-Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
-Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
org.apache.activemq.artemis.boot.Artemis run
2016-09-23 12:53:32 - Started 2576
{noformat}

When launched from the command-line (not using the service wrapper), Artemis 
will launch and run just fine.



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


[jira] [Updated] (ARTEMIS-750) Artemis Windows Service Fails to Start

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes updated ARTEMIS-750:
--
Attachment: errorstartingservice-screenshot.png

> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following 
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see 
> attached image).  When the service error log is checked, no error is logged. 
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java  "-Xbootclasspath/a:C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar" 
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M 
> -Xmx1024M -classpath "C:\Program 
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar" 
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0" 
> -Dartemis.instance=C:\ProgramData\Apache\AMQ 
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties 
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config 
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis 
> will launch and run just fine.



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


[jira] [Commented] (ARTEMIS-749) Version Number Does Not Display for Windows Service

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes commented on ARTEMIS-749:
---

This is using the shipping version of the binaries. I did not build them myself.

> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
>  Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number 
> correctly.  Instead, it displays 0.0.0.0.  Please see attached screenshot 
> showing the issue.



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


[jira] [Commented] (AMQ-6436) tmp_storage folder not cleaned on startup

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

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

https://issues.apache.org/jira/browse/AMQ-6436

The temporary store will now delete the old temp directory on start up
if lazyInit is true instead of waiting for the store to initialize to
clear up space.  This prevents space on the disk from being wasted with
old data if the temp store isn't initialized


> tmp_storage folder not cleaned on startup
> -
>
> Key: AMQ-6436
> URL: https://issues.apache.org/jira/browse/AMQ-6436
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.3
> Environment: Windows/RHEL 6.8 tested
>Reporter: Reid Sommerville
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: JMSTmpStor.java, message.txt
>
>
> saw this on our production servers, activemq failed to start due to no space 
> on the mount where tmp_storage was located. Reproduced it on a local windows 
> machine.
> start a default activemq broker at the command line.
> Run the attached code enough times to cause activemq to start writing to the 
> the tmp_storage folder, in my case 1 messages was enough to give me 513Mb 
> in tmp_storage
> restart activemq and note that the contents of the tmp_storage folder are 
> still intact. 



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


[jira] [Commented] (AMQ-6436) tmp_storage folder not cleaned on startup

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit b1c09d9a859c9caf6eccacdb23ca0b5f65f9b527 in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b1c09d9 ]

https://issues.apache.org/jira/browse/AMQ-6436

The temporary store will now delete the old temp directory on start up
if lazyInit is true instead of waiting for the store to initialize to
clear up space.  This prevents space on the disk from being wasted with
old data if the temp store isn't initialized

(cherry picked from commit a82c95cd29a6b06d2083b1869129b9e2addac7da)


> tmp_storage folder not cleaned on startup
> -
>
> Key: AMQ-6436
> URL: https://issues.apache.org/jira/browse/AMQ-6436
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.3
> Environment: Windows/RHEL 6.8 tested
>Reporter: Reid Sommerville
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: JMSTmpStor.java, message.txt
>
>
> saw this on our production servers, activemq failed to start due to no space 
> on the mount where tmp_storage was located. Reproduced it on a local windows 
> machine.
> start a default activemq broker at the command line.
> Run the attached code enough times to cause activemq to start writing to the 
> the tmp_storage folder, in my case 1 messages was enough to give me 513Mb 
> in tmp_storage
> restart activemq and note that the contents of the tmp_storage folder are 
> still intact. 



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


[jira] [Resolved] (AMQ-6436) tmp_storage folder not cleaned on startup

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon resolved AMQ-6436.
-
   Resolution: Fixed
Fix Version/s: 5.15.0
   5.14.1

> tmp_storage folder not cleaned on startup
> -
>
> Key: AMQ-6436
> URL: https://issues.apache.org/jira/browse/AMQ-6436
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.3
> Environment: Windows/RHEL 6.8 tested
>Reporter: Reid Sommerville
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: JMSTmpStor.java, message.txt
>
>
> saw this on our production servers, activemq failed to start due to no space 
> on the mount where tmp_storage was located. Reproduced it on a local windows 
> machine.
> start a default activemq broker at the command line.
> Run the attached code enough times to cause activemq to start writing to the 
> the tmp_storage folder, in my case 1 messages was enough to give me 513Mb 
> in tmp_storage
> restart activemq and note that the contents of the tmp_storage folder are 
> still intact. 



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


[jira] [Updated] (ARTEMIS-749) Version Number Does Not Display for Windows Service

2016-09-23 Thread Jim Gomes (JIRA)

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

Jim Gomes updated ARTEMIS-749:
--
Attachment: serviceinfo-screenshot.png

> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
>  Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number 
> correctly.  Instead, it displays 0.0.0.0.  Please see attached screenshot 
> showing the issue.



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


[jira] [Created] (ARTEMIS-749) Version Number Does Not Display for Windows Service

2016-09-23 Thread Jim Gomes (JIRA)
Jim Gomes created ARTEMIS-749:
-

 Summary: Version Number Does Not Display for Windows Service
 Key: ARTEMIS-749
 URL: https://issues.apache.org/jira/browse/ARTEMIS-749
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.4.0
 Environment: Windows 10 Anniversary Edition, 64-bit
Reporter: Jim Gomes
Priority: Minor
 Fix For: 1.5.0


When the Artemis service is registered using

{{artemis-service install}}

the registered service name does not display the embedded version number 
correctly.  Instead, it displays 0.0.0.0.  Please see attached screenshot 
showing the issue.



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


[jira] [Assigned] (AMQ-6436) tmp_storage folder not cleaned on startup

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon reassigned AMQ-6436:
---

Assignee: Christopher L. Shannon

> tmp_storage folder not cleaned on startup
> -
>
> Key: AMQ-6436
> URL: https://issues.apache.org/jira/browse/AMQ-6436
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.3
> Environment: Windows/RHEL 6.8 tested
>Reporter: Reid Sommerville
>Assignee: Christopher L. Shannon
> Attachments: JMSTmpStor.java, message.txt
>
>
> saw this on our production servers, activemq failed to start due to no space 
> on the mount where tmp_storage was located. Reproduced it on a local windows 
> machine.
> start a default activemq broker at the command line.
> Run the attached code enough times to cause activemq to start writing to the 
> the tmp_storage folder, in my case 1 messages was enough to give me 513Mb 
> in tmp_storage
> restart activemq and note that the contents of the tmp_storage folder are 
> still intact. 



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


[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-737:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
@hqstevenson  I was looking more for a single example on how to use your 
annotations. Something we could add a chapter within the documentation.



> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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


[jira] [Resolved] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon resolved AMQ-6431.
-
   Resolution: Fixed
Fix Version/s: 5.15.0
   5.14.1

> BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE
> --
>
> Key: AMQ-6431
> URL: https://issues.apache.org/jira/browse/AMQ-6431
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.14.0
>Reporter: 王庆焕
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: BitArrayBinTest.java
>
>
> I have a problem with "messageid deplicate". Then I found it's a 
> bug(AMQ-5016) in activemq5.9.0 , so I download the activemq5.14.0. I run the 
> BitArrayBinTest.java:
> {code}
>  public static void main(String[] args) {
>BitArrayBin toTest = new BitArrayBin(1024);
>long largeNum = Integer.MAX_VALUE*2L +100L;
>toTest.setBit(largeNum, true);
>System.out.println(toTest.getBit(largeNum));   
> }
> {code}
>  I expect the results to be "true",but the result of running the above code 
> is "false". 
> I debug the code,and I  found a method 'getBin(long index)' in class 
> BitArrayBin. Code as follows:
> {code}
> private int getBin(long index) {
> int answer = 0;
> if (longFirstIndex < 0) {
> longFirstIndex = (int) (index - (index % BitArray.LONG_SIZE));
> } else if (longFirstIndex >= 0) {
> answer = (int)((index - longFirstIndex) / BitArray.LONG_SIZE);
> }
> return answer;
> }
> {code}
>  I think the problem is in  code ‘longFirstIndex = (int) (index - (index % 
> BitArray.LONG_SIZE))‘.  When  index is larger than Integer.MAX_VALUE, 
> longFirstIndex will be negative.  I think this line of code should be 
> modified to  ‘longFirstIndex = (long) (index - (index % BitArray.LONG_SIZE));’
>
> 



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


[jira] [Commented] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit bf7a19eead5ed9fac08f4220a3ec82dc6abdb7e3 in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=bf7a19e ]

https://issues.apache.org/jira/browse/AMQ-6431

Fixing BitArrayBin to not overflow in certain cases with numbers larger
than Int max

(cherry picked from commit 09456480b838efd97297679840d33f7949449e21)


> BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE
> --
>
> Key: AMQ-6431
> URL: https://issues.apache.org/jira/browse/AMQ-6431
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.14.0
>Reporter: 王庆焕
>Assignee: Christopher L. Shannon
> Attachments: BitArrayBinTest.java
>
>
> I have a problem with "messageid deplicate". Then I found it's a 
> bug(AMQ-5016) in activemq5.9.0 , so I download the activemq5.14.0. I run the 
> BitArrayBinTest.java:
> {code}
>  public static void main(String[] args) {
>BitArrayBin toTest = new BitArrayBin(1024);
>long largeNum = Integer.MAX_VALUE*2L +100L;
>toTest.setBit(largeNum, true);
>System.out.println(toTest.getBit(largeNum));   
> }
> {code}
>  I expect the results to be "true",but the result of running the above code 
> is "false". 
> I debug the code,and I  found a method 'getBin(long index)' in class 
> BitArrayBin. Code as follows:
> {code}
> private int getBin(long index) {
> int answer = 0;
> if (longFirstIndex < 0) {
> longFirstIndex = (int) (index - (index % BitArray.LONG_SIZE));
> } else if (longFirstIndex >= 0) {
> answer = (int)((index - longFirstIndex) / BitArray.LONG_SIZE);
> }
> return answer;
> }
> {code}
>  I think the problem is in  code ‘longFirstIndex = (int) (index - (index % 
> BitArray.LONG_SIZE))‘.  When  index is larger than Integer.MAX_VALUE, 
> longFirstIndex will be negative.  I think this line of code should be 
> modified to  ‘longFirstIndex = (long) (index - (index % BitArray.LONG_SIZE));’
>
> 



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


[jira] [Assigned] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon reassigned AMQ-6431:
---

Assignee: Christopher L. Shannon

> BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE
> --
>
> Key: AMQ-6431
> URL: https://issues.apache.org/jira/browse/AMQ-6431
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.14.0
>Reporter: 王庆焕
>Assignee: Christopher L. Shannon
> Attachments: BitArrayBinTest.java
>
>
> I have a problem with "messageid deplicate". Then I found it's a 
> bug(AMQ-5016) in activemq5.9.0 , so I download the activemq5.14.0. I run the 
> BitArrayBinTest.java:
> {code}
>  public static void main(String[] args) {
>BitArrayBin toTest = new BitArrayBin(1024);
>long largeNum = Integer.MAX_VALUE*2L +100L;
>toTest.setBit(largeNum, true);
>System.out.println(toTest.getBit(largeNum));   
> }
> {code}
>  I expect the results to be "true",but the result of running the above code 
> is "false". 
> I debug the code,and I  found a method 'getBin(long index)' in class 
> BitArrayBin. Code as follows:
> {code}
> private int getBin(long index) {
> int answer = 0;
> if (longFirstIndex < 0) {
> longFirstIndex = (int) (index - (index % BitArray.LONG_SIZE));
> } else if (longFirstIndex >= 0) {
> answer = (int)((index - longFirstIndex) / BitArray.LONG_SIZE);
> }
> return answer;
> }
> {code}
>  I think the problem is in  code ‘longFirstIndex = (int) (index - (index % 
> BitArray.LONG_SIZE))‘.  When  index is larger than Integer.MAX_VALUE, 
> longFirstIndex will be negative.  I think this line of code should be 
> modified to  ‘longFirstIndex = (long) (index - (index % BitArray.LONG_SIZE));’
>
> 



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


[jira] [Commented] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit 09456480b838efd97297679840d33f7949449e21 in activemq's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=0945648 ]

https://issues.apache.org/jira/browse/AMQ-6431

Fixing BitArrayBin to not overflow in certain cases with numbers larger
than Int max


> BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE
> --
>
> Key: AMQ-6431
> URL: https://issues.apache.org/jira/browse/AMQ-6431
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.14.0
>Reporter: 王庆焕
>Assignee: Christopher L. Shannon
> Attachments: BitArrayBinTest.java
>
>
> I have a problem with "messageid deplicate". Then I found it's a 
> bug(AMQ-5016) in activemq5.9.0 , so I download the activemq5.14.0. I run the 
> BitArrayBinTest.java:
> {code}
>  public static void main(String[] args) {
>BitArrayBin toTest = new BitArrayBin(1024);
>long largeNum = Integer.MAX_VALUE*2L +100L;
>toTest.setBit(largeNum, true);
>System.out.println(toTest.getBit(largeNum));   
> }
> {code}
>  I expect the results to be "true",but the result of running the above code 
> is "false". 
> I debug the code,and I  found a method 'getBin(long index)' in class 
> BitArrayBin. Code as follows:
> {code}
> private int getBin(long index) {
> int answer = 0;
> if (longFirstIndex < 0) {
> longFirstIndex = (int) (index - (index % BitArray.LONG_SIZE));
> } else if (longFirstIndex >= 0) {
> answer = (int)((index - longFirstIndex) / BitArray.LONG_SIZE);
> }
> return answer;
> }
> {code}
>  I think the problem is in  code ‘longFirstIndex = (int) (index - (index % 
> BitArray.LONG_SIZE))‘.  When  index is larger than Integer.MAX_VALUE, 
> longFirstIndex will be negative.  I think this line of code should be 
> modified to  ‘longFirstIndex = (long) (index - (index % BitArray.LONG_SIZE));’
>
> 



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


[jira] [Closed] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon closed AMQ-6441.
---
Resolution: Not A Problem

Closing as not a problem as we use the Java File api and can't control if the 
value overflows a long.

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6441:
-

Yep, nothing can really be done here because it's a JDK api method that returns 
a long.  The only real solution is to use something like the BigInteger class 
but that can't be done in this case since we don't control the method call.  So 
you probably will need to just configure a smaller partition for your broker.

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread William Crowell (JIRA)

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

William Crowell commented on AMQ-6441:
--

Unfortunately, I think you are right.  The user would need to move to JDK 1.8 
so an unsigned long is returned.

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6441:
-

I think you are right, I was thinking that the value would still fit into a 
long but looks like it is just a bit too large as you pointed out to fit in a 
long value.

But I don't see how changing totalSpace to a double would do anything.  
java.io.File.getTotalSpace() would still overflow and return a negative long 
value which would then just become a negative double.

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread William Crowell (JIRA)

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

William Crowell commented on AMQ-6441:
--

I have a theory that a long is not large enough to represent 8,796,093,022,208 
megabytes, and we are running into an overflow issue.

Given that a long primitive type in Java 7 has a range of -2 to the 63rd power 
and a maximum value of 2 to the 63rd power -1.

This means that a long can have values -9,223,372,036,854,775,808 to 
9,223,372,036,854,775,807.

If I convert 8796093022208 megabytes into bytes then that value is 
9,223,372,036,854,780,000 which is 4,193 outside the maximum value of a long.

If you happen to be running Java 8, then a unsigned 64-bit long can have a 
maximum value of 18,446,744,073,709,500,000.  

This means that the call to Java's java.io.File.getTotalSpace() would overflow 
since it returns a long: 
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#getTotalSpace()

In Java 8, this probably works fine.  Could I propose changing the variable on 
line 2050 of org.apache.activemq.broker.BrokerService to a double instead of a 
long?

...
double totalSpace = dir.getTotalSpace();
...  
 
>From the link: 
>https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

"The double data type is a double-precision 64-bit IEEE 754 floating point."

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Comment Edited] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread William Crowell (JIRA)

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

William Crowell edited comment on AMQ-6441 at 9/23/16 5:25 PM:
---

I have a theory that a long is not large enough to represent 8,796,093,022,208 
megabytes, and we are running into an overflow issue.

Given that a long primitive type in Java 7 has a range of -2 to the 63rd power 
and a maximum value of 2 to the 63rd power -1.

This means that a long can have values -9,223,372,036,854,775,808 to 
9,223,372,036,854,775,807.

If I convert 8796093022208 megabytes into bytes then that value is 
9,223,372,036,854,780,000 which is 4,193 outside the maximum value of a long.

If you happen to be running Java 8, then a unsigned 64-bit long can have a 
maximum value of 18,446,744,073,709,500,000 which would be large enough.

This means that the call to Java's java.io.File.getTotalSpace() would overflow 
since it returns a long: 
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#getTotalSpace()

In Java 8, this probably works fine.  Could I propose changing the variable on 
line 2050 of org.apache.activemq.broker.BrokerService to a double instead of a 
long?

...
double totalSpace = dir.getTotalSpace();
...  
 
>From the link: 
>https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

"The double data type is a double-precision 64-bit IEEE 754 floating point."


was (Author: william.crowell):
I have a theory that a long is not large enough to represent 8,796,093,022,208 
megabytes, and we are running into an overflow issue.

Given that a long primitive type in Java 7 has a range of -2 to the 63rd power 
and a maximum value of 2 to the 63rd power -1.

This means that a long can have values -9,223,372,036,854,775,808 to 
9,223,372,036,854,775,807.

If I convert 8796093022208 megabytes into bytes then that value is 
9,223,372,036,854,780,000 which is 4,193 outside the maximum value of a long.

If you happen to be running Java 8, then a unsigned 64-bit long can have a 
maximum value of 18,446,744,073,709,500,000.  

This means that the call to Java's java.io.File.getTotalSpace() would overflow 
since it returns a long: 
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#getTotalSpace()

In Java 8, this probably works fine.  Could I propose changing the variable on 
line 2050 of org.apache.activemq.broker.BrokerService to a double instead of a 
long?

...
double totalSpace = dir.getTotalSpace();
...  
 
>From the link: 
>https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

"The double data type is a double-precision 64-bit IEEE 754 floating point."

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (ARTEMIS-747) Multiple CDATA events during import fails

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-747:


Github user asfgit closed the pull request at:

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


> Multiple CDATA events during import fails
> -
>
> Key: ARTEMIS-747
> URL: https://issues.apache.org/jira/browse/ARTEMIS-747
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> Message bodies are written to XML as Base64 encoded CDATA elements. Some 
> parser implementations won't read the entire CDATA element at once (e.g. 
> Woodstox) so it's possible for multiple CDATA events to be combined into a 
> single Base64 encoded string.  You can't decode bits and pieces of each 
> CDATA.  Each CDATA has to be decoded in its entirety.  The current importer 
> doesn't deal with this properly.



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


[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-737:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
@hqstevenson the idea here is to provide final users the capability of 
running junit tests with a messaging server, right?


It would be nice to have at least an example on how to do this.. can you 
add at least one test as an example?


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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


[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-737:


Github user hqstevenson commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
I'd be happy to add an example, but I'm not sure exactly what you're 
looking for.  All of the unit tests show the basics of how you embed a sever 
into your test, and how you use the server afterwards.

Is there a specific type of test you'd like to see?

BTW - once this is released, I'm going to contribute a 
"example-camel-artemis" to the Camel project - that will show how to use the 
embedded resources with Camel.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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


[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-737:


Github user hqstevenson commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
I fixed the check style issues, and I also added constructors to the 
EmbeddedXXXResource rules to allow configuring the servers with configuration 
files.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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


[jira] [Commented] (ARTEMIS-747) Multiple CDATA events during import fails

2016-09-23 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on ARTEMIS-747:
-

Commit ea552a1f88c1cbc1a3e9352a936c428db5af9527 in activemq-artemis's branch 
refs/heads/master from jbertram
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ea552a1 ]

ARTEMIS-747 multiple CDATA events on import fails


> Multiple CDATA events during import fails
> -
>
> Key: ARTEMIS-747
> URL: https://issues.apache.org/jira/browse/ARTEMIS-747
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> Message bodies are written to XML as Base64 encoded CDATA elements. Some 
> parser implementations won't read the entire CDATA element at once (e.g. 
> Woodstox) so it's possible for multiple CDATA events to be combined into a 
> single Base64 encoded string.  You can't decode bits and pieces of each 
> CDATA.  Each CDATA has to be decoded in its entirety.  The current importer 
> doesn't deal with this properly.



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


[jira] [Commented] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6441:
-

I'm not really sure why it's doing that because all of the usage and limit 
calculations use a long.  Since none of the developers have anything near that 
size of disk space to test on you will probably have to do some more debugging 
on your end to see what the problem is.  The code where the limits are checked 
is here: 
https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java#L2044

You could try setting up a remote debugger and some break points to see where 
the value is going bad.  The other option is you can add some logging 
statements to the code and rebuild it, etc. and deploy the rebuilt version.

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit e0c70b843fb963cfa5e3be322c0d271ba61709bb in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e0c70b8 ]

https://issues.apache.org/jira/browse/AMQ-6430

Modifying patch so that only stores that persist the noLocal flag will
check if this flag has changed to prevent a subscription from being
deleted by mistake

(cherry picked from commit 18571ce09b6385d8560200928a353e9da1a1ffe4)


> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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


[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit 18571ce09b6385d8560200928a353e9da1a1ffe4 in activemq's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=18571ce ]

https://issues.apache.org/jira/browse/AMQ-6430

Modifying patch so that only stores that persist the noLocal flag will
check if this flag has changed to prevent a subscription from being
deleted by mistake


> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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


[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6430:
-

There are some test failures because JDBC and LevelDB don't support storing the 
noLocal flag.  Working on a fix now such that the noLocal flag only applies to 
stores that persist the flag (currently the memory store and kahadb/multikahadb 
when using openwire version >=11).  If JDBC and LevelDB are updated in the 
future such that this flag is stored then an update can be done so that this 
patch applies to those stores as well.

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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


[jira] [Updated] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Ismail Bhana (JIRA)

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

Ismail Bhana updated AMQ-6441:
--
Description: 
I've set up Active MQ in production with a shared file system master/slave 
configuration (KahaDB). I've set everything up and mounted the EFS on both EC2 
instances. 

When I check the disk free stats I get 8 exabytes for the shared file system: 

{code}
$ df -h 
eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
{code}

Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may be 
due to integer truncation.

Here is a snippet of the log:

{code}
Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
/mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
maximum available disk space: -8796093022207 mb 
Store limit is -8796093022207 mb, whilst the max journal file size for the 
store is: 32 mb, the store will not accept any data when used. 
{code}

  was:
I've set up Active MQ in production with a shared file system master/slave 
configuration (KahaDB). I've set everything up and mounted the EFS on both EC2 
instances. 

When I check the disk free stats I get 8 exabytes for the shared file system: 

$ df -h 
eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
Unfortunately, ActiveMQ cannot interpret this number: 

Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
/mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
maximum available disk space: -8796093022207 mb 
Store limit is -8796093022207 mb, whilst the max journal file size for the 
store is: 32 mb, the store will not accept any data when used. 


> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



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


[jira] [Updated] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Ismail Bhana (JIRA)

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

Ismail Bhana updated AMQ-6441:
--
Description: 
I've set up Active MQ in production with a shared file system master/slave 
configuration (KahaDB). I've set everything up and mounted the EFS on both EC2 
instances. 

When I check the disk free stats I get 8 exabytes for the shared file system: 

$ df -h 
eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
Unfortunately, ActiveMQ cannot interpret this number: 

Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
/mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
maximum available disk space: -8796093022207 mb 
Store limit is -8796093022207 mb, whilst the max journal file size for the 
store is: 32 mb, the store will not accept any data when used. 

  was:
I'm setting up Active MQ in production with a shared file system master/slave 
configuration (KahaDB). I've set everything up and mounted the EFS on both EC2 
instances. 

When I check the disk free stats I get 8 exabytes for the shared file system: 

$ df -h 
eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
Unfortunately, ActiveMQ cannot interpret this number: 

Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
/mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
maximum available disk space: -8796093022207 mb 
Store limit is -8796093022207 mb, whilst the max journal file size for the 
store is: 32 mb, the store will not accept any data when used. 


> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -
>
> Key: AMQ-6441
> URL: https://issues.apache.org/jira/browse/AMQ-6441
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
>Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
> Unfortunately, ActiveMQ cannot interpret this number: 
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 



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


[jira] [Created] (AMQ-6441) Incorrect File System Size Reported with Amazon Elastic File System (EFS)

2016-09-23 Thread Ismail Bhana (JIRA)
Ismail Bhana created AMQ-6441:
-

 Summary: Incorrect File System Size Reported with Amazon Elastic 
File System (EFS)
 Key: AMQ-6441
 URL: https://issues.apache.org/jira/browse/AMQ-6441
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.11.1
Reporter: Ismail Bhana


I'm setting up Active MQ in production with a shared file system master/slave 
configuration (KahaDB). I've set everything up and mounted the EFS on both EC2 
instances. 

When I check the disk free stats I get 8 exabytes for the shared file system: 

$ df -h 
eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E 0  8.0E   0% /mnt/efs 
Unfortunately, ActiveMQ cannot interpret this number: 

Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
/mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
maximum available disk space: -8796093022207 mb 
Store limit is -8796093022207 mb, whilst the max journal file size for the 
store is: 32 mb, the store will not accept any data when used. 



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


[jira] [Commented] (ARTEMIS-714) JDBC Store improvement

2016-09-23 Thread Martyn Taylor (JIRA)

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

Martyn Taylor commented on ARTEMIS-714:
---

Great.  I'll close this out then.

> JDBC Store improvement
> --
>
> Key: ARTEMIS-714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-714
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
> Fix For: 1.5.0
>
>
> We plan to integrate with Artemis JDBC store in our application server.
> After a code review, we saw 2 main improvements that would make the code more 
> flexible and easier to maintain.
> First, in our app server, we have our sophisticated way to configure access 
> to databases. We would like to be able to pass a DataSource instance to 
> Artemis JDBC store instead of a (driver class name / URL) tuple. 
> If the DataSource object is set, we create a Connection from it, otherwise we 
> use the current code to create the connection from a class name + URL. This 
> will introduce no changes to use of standalone Artemis broker.
> The second improvement is to make the SQLProvider injectable instead of 
> relying on hard-coded class provided by Artemis jars.
> We would create an instance of the SQLProvider in our integration code and 
> pass it to Artemis JDBC store. This will make it simpler to support new types 
> of databases (or fix issues in the SQLProvider implementations) without 
> requiring a new release of Artemis for that.
> If the SQLProvider instance injected in the JDBC store is null, the current 
> code will be executed.
> Does these improvements sound correct?



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


[jira] [Resolved] (ARTEMIS-714) JDBC Store improvement

2016-09-23 Thread Martyn Taylor (JIRA)

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

Martyn Taylor resolved ARTEMIS-714.
---
Resolution: Fixed

> JDBC Store improvement
> --
>
> Key: ARTEMIS-714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-714
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
> Fix For: 1.5.0
>
>
> We plan to integrate with Artemis JDBC store in our application server.
> After a code review, we saw 2 main improvements that would make the code more 
> flexible and easier to maintain.
> First, in our app server, we have our sophisticated way to configure access 
> to databases. We would like to be able to pass a DataSource instance to 
> Artemis JDBC store instead of a (driver class name / URL) tuple. 
> If the DataSource object is set, we create a Connection from it, otherwise we 
> use the current code to create the connection from a class name + URL. This 
> will introduce no changes to use of standalone Artemis broker.
> The second improvement is to make the SQLProvider injectable instead of 
> relying on hard-coded class provided by Artemis jars.
> We would create an instance of the SQLProvider in our integration code and 
> pass it to Artemis JDBC store. This will make it simpler to support new types 
> of databases (or fix issues in the SQLProvider implementations) without 
> requiring a new release of Artemis for that.
> If the SQLProvider instance injected in the JDBC store is null, the current 
> code will be executed.
> Does these improvements sound correct?



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


[jira] [Updated] (ARTEMIS-714) JDBC Store improvement

2016-09-23 Thread Martyn Taylor (JIRA)

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

Martyn Taylor updated ARTEMIS-714:
--
Fix Version/s: 1.5.0

> JDBC Store improvement
> --
>
> Key: ARTEMIS-714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-714
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
> Fix For: 1.5.0
>
>
> We plan to integrate with Artemis JDBC store in our application server.
> After a code review, we saw 2 main improvements that would make the code more 
> flexible and easier to maintain.
> First, in our app server, we have our sophisticated way to configure access 
> to databases. We would like to be able to pass a DataSource instance to 
> Artemis JDBC store instead of a (driver class name / URL) tuple. 
> If the DataSource object is set, we create a Connection from it, otherwise we 
> use the current code to create the connection from a class name + URL. This 
> will introduce no changes to use of standalone Artemis broker.
> The second improvement is to make the SQLProvider injectable instead of 
> relying on hard-coded class provided by Artemis jars.
> We would create an instance of the SQLProvider in our integration code and 
> pass it to Artemis JDBC store. This will make it simpler to support new types 
> of databases (or fix issues in the SQLProvider implementations) without 
> requiring a new release of Artemis for that.
> If the SQLProvider instance injected in the JDBC store is null, the current 
> code will be executed.
> Does these improvements sound correct?



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


[jira] [Commented] (ARTEMIS-742) replication quorum broken

2016-09-23 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on ARTEMIS-742:
-

Commit 4c1d9e2c0f5799477b002a1fb643b8acf554fc4b in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4c1d9e2 ]

 ARTEMIS-742 = test fixes

https://issues.apache.org/jira/browse/ARTEMIS-742


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.5.0
>
>




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


[jira] [Commented] (ARTEMIS-742) replication quorum broken

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-742:


Github user asfgit closed the pull request at:

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


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.5.0
>
>




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


[jira] [Commented] (ARTEMIS-742) replication quorum broken

2016-09-23 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on ARTEMIS-742:
-

Commit 4c1d9e2c0f5799477b002a1fb643b8acf554fc4b in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4c1d9e2 ]

 ARTEMIS-742 = test fixes

https://issues.apache.org/jira/browse/ARTEMIS-742


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.5.0
>
>




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


[jira] [Resolved] (AMQ-6433) Missing check for null parameter in equals()

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon resolved AMQ-6433.
-
   Resolution: Fixed
Fix Version/s: 5.15.0
   5.14.1

> Missing check for null parameter in equals()
> 
>
> Key: AMQ-6433
> URL: https://issues.apache.org/jira/browse/AMQ-6433
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kaloyan Spiridonov
>Assignee: Christopher L. Shannon
>Priority: Trivial
> Fix For: 5.14.1, 5.15.0
>
>
> In equals() method in TypeConversionSupport class there is missing check for 
> null parameter.
> According to javadoc of Object class: For any non-null reference value x, 
> x.equals(null) should return false.



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


[jira] [Commented] (AMQ-6434) Return inside finally

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit a80f7ccbe1c0e60c3aa668b33e4dbdc3dbb21128 in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=a80f7cc ]

https://issues.apache.org/jira/browse/AMQ-6434

Rewriting logic in finally block of PooledTaskRunner to avoid using a
return statement

(cherry picked from commit f25e7ab47f1bed223e30fc85afbe43ba1f4c93e6)


> Return inside finally
> -
>
> Key: AMQ-6434
> URL: https://issues.apache.org/jira/browse/AMQ-6434
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kaloyan Spiridonov
>Assignee: Christopher L. Shannon
>Priority: Trivial
>
> In runTask() method in PooledTaskRunner class there is an return statement in 
> finally block. This will cause any exception that might be thrown in the try 
> block to be discarded.



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


[jira] [Commented] (AMQ-6433) Missing check for null parameter in equals()

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

Commit 8bde32a07c28500793924b183f2956e8cc6b13f4 in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=8bde32a ]

https://issues.apache.org/jira/browse/AMQ-6433

Generating a new equals method in TypeConversionSupport so the proper
null checks exist

(cherry picked from commit 2b99ffcc22e8c982883ae553bd91d03acc68aaa2)


> Missing check for null parameter in equals()
> 
>
> Key: AMQ-6433
> URL: https://issues.apache.org/jira/browse/AMQ-6433
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kaloyan Spiridonov
>Assignee: Christopher L. Shannon
>Priority: Trivial
>
> In equals() method in TypeConversionSupport class there is missing check for 
> null parameter.
> According to javadoc of Object class: For any non-null reference value x, 
> x.equals(null) should return false.



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


[jira] [Commented] (AMQ-6434) Return inside finally

2016-09-23 Thread ASF subversion and git services (JIRA)

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

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

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

https://issues.apache.org/jira/browse/AMQ-6434

Rewriting logic in finally block of PooledTaskRunner to avoid using a
return statement


> Return inside finally
> -
>
> Key: AMQ-6434
> URL: https://issues.apache.org/jira/browse/AMQ-6434
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kaloyan Spiridonov
>Assignee: Christopher L. Shannon
>Priority: Trivial
>
> In runTask() method in PooledTaskRunner class there is an return statement in 
> finally block. This will cause any exception that might be thrown in the try 
> block to be discarded.



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


[jira] [Assigned] (AMQ-6434) Return inside finally

2016-09-23 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon reassigned AMQ-6434:
---

Assignee: Christopher L. Shannon

> Return inside finally
> -
>
> Key: AMQ-6434
> URL: https://issues.apache.org/jira/browse/AMQ-6434
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Kaloyan Spiridonov
>Assignee: Christopher L. Shannon
>Priority: Trivial
>
> In runTask() method in PooledTaskRunner class there is an return statement in 
> finally block. This will cause any exception that might be thrown in the try 
> block to be discarded.



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


[jira] [Commented] (AMQCPP-601) PriorityBackup isn't working

2016-09-23 Thread Michele Bozzaotre (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQCPP-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515922#comment-15515922
 ] 

Michele Bozzaotre commented on AMQCPP-601:
--

Hi Tim,
Did you plan to solve this issue in some future versions?

> PriorityBackup isn't working
> 
>
> Key: AMQCPP-601
> URL: https://issues.apache.org/jira/browse/AMQCPP-601
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>Affects Versions: 3.7.0, 3.9.3
> Environment: MSVC (Toolset v90), 
>Reporter: Jawad Bokhari
>Assignee: Timothy Bish
>
> I am trying to take advantage of the ActiveMQ priority backup feature.
> I'm running 2 brokers on 2 different sites (machines). Each site has 2 AMQ 
> clients, one of which is a Java client and the other one is a C++ client.
> Both brokers are linked as network of brokers in duplex mode. 
> I want the following behavior for my apps.
> * Always connect to local broker on startup
> * If local broker goes down, connect to the remote
> * {color:red} While connected to remote, if local comes back up, we then 
> reconnect to local. {color}
> This works on my java app by simply adding priorityBackup to my URI options 
> ??failover:(tcp://local:61616,tcp://remote:61616)?randomize=false=true??
> However, the part highlighted in {color:red}red{color} doesn't work for CPP 
> client.
> The following works fine on the CPP apps (with basic working failover 
> functionality - aka jumping to remote when local goes down )
> ??failover:(tcp://local:61616,tcp://remote:61616)?randomize=false??
> But updating the uri options with priorityBackup even breaks failover 
> functionality completely (my apps never failover to the remote broker, they 
> just stay in some kind of broker-less/limbo state when their local broker 
> goes down) 
> ??failover:(tcp://local:61616,tcp://remote:61616)?randomize=false{color:red}=true{color}??
> I tried this with 3.9.3 without success. Then, I tried with the version 3.7.0 
> when this feature *priorityBackup* was first introduced but without luck.
> ActiveMQ broker versions: *5.9.0*, *5.13.2*
> I'm using Visual Studio 2008 toolset (V90) for my client application. 



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


[jira] [Commented] (ARTEMIS-747) Multiple CDATA events during import fails

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-747:


Github user TomasHofman commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/791#discussion_r80204402
  
--- Diff: 
artemis-cli/src/main/java/org/apache/activemq/artemis/cli/commands/tools/XmlDataImporter.java
 ---
@@ -444,33 +444,59 @@ private void processMessageBody(Message message) 
throws XMLStreamException, IOEx
  }
   }
   reader.next();
+  ActiveMQServerLogger.LOGGER.debug("XMLStreamReader impl: " + reader);
   if (isLarge) {
  tempFileName = UUID.randomUUID().toString() + ".tmp";
  ActiveMQServerLogger.LOGGER.debug("Creating temp file " + 
tempFileName + " for large message.");
  try (OutputStream out = new FileOutputStream(tempFileName)) {
-while (reader.hasNext()) {
-   if (reader.getEventType() == 
XMLStreamConstants.END_ELEMENT) {
-  break;
-   }
-   else {
-  String characters = new 
String(reader.getTextCharacters(), reader.getTextStart(), 
reader.getTextLength());
-  String trimmedCharacters = characters.trim();
-  if (trimmedCharacters.length() > 0) { // this will skip 
"indentation" characters
- byte[] data = decode(trimmedCharacters);
- out.write(data);
-  }
-   }
-   reader.next();
-}
+getMessageBodyBytes(new MessageBodyBytesProcessor() {
+   @Override
+   public void processBodyBytes(byte[] bytes) throws 
IOException {
+  out.write(bytes);
+   }
+});
  }
  FileInputStream fileInputStream = new 
FileInputStream(tempFileName);
  BufferedInputStream bufferedInput = new 
BufferedInputStream(fileInputStream);
  ((ClientMessage) message).setBodyInputStream(bufferedInput);
   }
   else {
- reader.next(); // step past the "indentation" characters to get 
to the CDATA with the message body
- String characters = new String(reader.getTextCharacters(), 
reader.getTextStart(), reader.getTextLength());
- message.getBodyBuffer().writeBytes(decode(characters.trim()));
+ getMessageBodyBytes(new MessageBodyBytesProcessor() {
+@Override
+public void processBodyBytes(byte[] bytes) throws IOException {
+   message.getBodyBuffer().writeBytes(bytes);
+}
+ });
+  }
+   }
+
+   /**
+* Message bodies are written to XML as Base64 encoded CDATA elements. 
Some parser implementations won't read the
+* entire CDATA element at once (e.g. Woodstox) so it's possible for 
multiple CDATA events to be combined into a
+* single Base64 encoded string.  You can't decode bits and pieces of 
each CDATA.  Each CDATA has to be decoded in
+* its entirety.
+*
+* @param processor used to deal with the decoded CDATA elements
+* @throws IOException
+* @throws XMLStreamException
+*/
+   private void getMessageBodyBytes(MessageBodyBytesProcessor processor) 
throws IOException, XMLStreamException {
+  int currentEventType;
+  StringBuilder cdata = new StringBuilder();
+  while (reader.hasNext()) {
+ currentEventType = reader.getEventType();
+ if (currentEventType == XMLStreamConstants.END_ELEMENT) {
+break;
+ }
+ // when we hit a CHARACTERS event we know that the entire CDATA 
is complete so decode and pass back to the processor
+ else if (currentEventType == XMLStreamConstants.CHARACTERS && 
cdata.length() > 0) {
--- End diff --

Although the problem would only occur if JDK's STAX implementation happened 
to fragment the the CDATA, which it (probably?) doesn't do. So it may be OK how 
it is.


> Multiple CDATA events during import fails
> -
>
> Key: ARTEMIS-747
> URL: https://issues.apache.org/jira/browse/ARTEMIS-747
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> Message bodies are written to XML as Base64 encoded CDATA elements. Some 
> parser implementations won't read the entire CDATA element at once (e.g. 
> Woodstox) so it's possible for multiple CDATA events to be combined into a 
> single Base64 encoded string.  You can't 

[jira] [Commented] (ARTEMIS-747) Multiple CDATA events during import fails

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-747:


Github user TomasHofman commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/791#discussion_r80201908
  
--- Diff: 
artemis-cli/src/main/java/org/apache/activemq/artemis/cli/commands/tools/XmlDataImporter.java
 ---
@@ -444,33 +444,59 @@ private void processMessageBody(Message message) 
throws XMLStreamException, IOEx
  }
   }
   reader.next();
+  ActiveMQServerLogger.LOGGER.debug("XMLStreamReader impl: " + reader);
   if (isLarge) {
  tempFileName = UUID.randomUUID().toString() + ".tmp";
  ActiveMQServerLogger.LOGGER.debug("Creating temp file " + 
tempFileName + " for large message.");
  try (OutputStream out = new FileOutputStream(tempFileName)) {
-while (reader.hasNext()) {
-   if (reader.getEventType() == 
XMLStreamConstants.END_ELEMENT) {
-  break;
-   }
-   else {
-  String characters = new 
String(reader.getTextCharacters(), reader.getTextStart(), 
reader.getTextLength());
-  String trimmedCharacters = characters.trim();
-  if (trimmedCharacters.length() > 0) { // this will skip 
"indentation" characters
- byte[] data = decode(trimmedCharacters);
- out.write(data);
-  }
-   }
-   reader.next();
-}
+getMessageBodyBytes(new MessageBodyBytesProcessor() {
+   @Override
+   public void processBodyBytes(byte[] bytes) throws 
IOException {
+  out.write(bytes);
+   }
+});
  }
  FileInputStream fileInputStream = new 
FileInputStream(tempFileName);
  BufferedInputStream bufferedInput = new 
BufferedInputStream(fileInputStream);
  ((ClientMessage) message).setBodyInputStream(bufferedInput);
   }
   else {
- reader.next(); // step past the "indentation" characters to get 
to the CDATA with the message body
- String characters = new String(reader.getTextCharacters(), 
reader.getTextStart(), reader.getTextLength());
- message.getBodyBuffer().writeBytes(decode(characters.trim()));
+ getMessageBodyBytes(new MessageBodyBytesProcessor() {
+@Override
+public void processBodyBytes(byte[] bytes) throws IOException {
+   message.getBodyBuffer().writeBytes(bytes);
+}
+ });
+  }
+   }
+
+   /**
+* Message bodies are written to XML as Base64 encoded CDATA elements. 
Some parser implementations won't read the
+* entire CDATA element at once (e.g. Woodstox) so it's possible for 
multiple CDATA events to be combined into a
+* single Base64 encoded string.  You can't decode bits and pieces of 
each CDATA.  Each CDATA has to be decoded in
+* its entirety.
+*
+* @param processor used to deal with the decoded CDATA elements
+* @throws IOException
+* @throws XMLStreamException
+*/
+   private void getMessageBodyBytes(MessageBodyBytesProcessor processor) 
throws IOException, XMLStreamException {
+  int currentEventType;
+  StringBuilder cdata = new StringBuilder();
+  while (reader.hasNext()) {
+ currentEventType = reader.getEventType();
+ if (currentEventType == XMLStreamConstants.END_ELEMENT) {
+break;
+ }
+ // when we hit a CHARACTERS event we know that the entire CDATA 
is complete so decode and pass back to the processor
+ else if (currentEventType == XMLStreamConstants.CHARACTERS && 
cdata.length() > 0) {
--- End diff --

JDK's STAX implementation reports CDATA sections also as 
XMLStreamConstants.CHARACTERS (instead of XMLStreamConstants.CDATA like 
Woodstox do) by default. So this condition needs to check that the text 
contains white spaces only. Probably reader.isWhiteSpace() should do.


> Multiple CDATA events during import fails
> -
>
> Key: ARTEMIS-747
> URL: https://issues.apache.org/jira/browse/ARTEMIS-747
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> Message bodies are written to XML as Base64 encoded CDATA elements. Some 
> parser implementations won't read the entire CDATA element at once (e.g. 
> Woodstox) so 

[jira] [Updated] (AMQ-6440) Include a 'KahaDBJournalReader' tool

2016-09-23 Thread Martin Lichtin (JIRA)

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

Martin Lichtin updated AMQ-6440:

Attachment: KahaDBJournalReader.tgz

> Include a 'KahaDBJournalReader' tool
> 
>
> Key: AMQ-6440
> URL: https://issues.apache.org/jira/browse/AMQ-6440
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Martin Lichtin
> Attachments: KahaDBJournalReader.tgz
>
>
> Some time ago, Adrian wrote a KahaDBJournalReader tool and published it at 
> https://issues.jboss.org/browse/MB-756
> Would be great to have this tool available as part of the ActiveMQ 
> distribution.



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


[jira] [Updated] (AMQ-6440) Include a 'KahaDBJournalReader' tool

2016-09-23 Thread Martin Lichtin (JIRA)

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

Martin Lichtin updated AMQ-6440:

Description: 
Some time ago, Adrian wrote a KahaDBJournalReader tool and published it at 
https://issues.jboss.org/browse/MB-756

Would be great to have this tool available as part of the ActiveMQ distribution.

  was:
Some time ago, Adrian wrote a KahaDBJournalReader too
and published it at https://issues.jboss.org/browse/MB-756

Would be great to have this tool available as part of the distribution.


> Include a 'KahaDBJournalReader' tool
> 
>
> Key: AMQ-6440
> URL: https://issues.apache.org/jira/browse/AMQ-6440
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Martin Lichtin
>
> Some time ago, Adrian wrote a KahaDBJournalReader tool and published it at 
> https://issues.jboss.org/browse/MB-756
> Would be great to have this tool available as part of the ActiveMQ 
> distribution.



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


[jira] [Created] (AMQ-6440) Include a 'KahaDBJournalReader' tool

2016-09-23 Thread Martin Lichtin (JIRA)
Martin Lichtin created AMQ-6440:
---

 Summary: Include a 'KahaDBJournalReader' tool
 Key: AMQ-6440
 URL: https://issues.apache.org/jira/browse/AMQ-6440
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: Martin Lichtin


Some time ago, Adrian wrote a KahaDBJournalReader too
and published it at https://issues.jboss.org/browse/MB-756

Would be great to have this tool available as part of the distribution.



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


[jira] [Commented] (ARTEMIS-714) JDBC Store improvement

2016-09-23 Thread Jeff Mesnil (JIRA)

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

Jeff Mesnil commented on ARTEMIS-714:
-

[~martyntaylor] I think so, I was able to write a POC that pass the DataSource 
from our app server to Artemis and it worked fine.

> JDBC Store improvement
> --
>
> Key: ARTEMIS-714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-714
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>
> We plan to integrate with Artemis JDBC store in our application server.
> After a code review, we saw 2 main improvements that would make the code more 
> flexible and easier to maintain.
> First, in our app server, we have our sophisticated way to configure access 
> to databases. We would like to be able to pass a DataSource instance to 
> Artemis JDBC store instead of a (driver class name / URL) tuple. 
> If the DataSource object is set, we create a Connection from it, otherwise we 
> use the current code to create the connection from a class name + URL. This 
> will introduce no changes to use of standalone Artemis broker.
> The second improvement is to make the SQLProvider injectable instead of 
> relying on hard-coded class provided by Artemis jars.
> We would create an instance of the SQLProvider in our integration code and 
> pass it to Artemis JDBC store. This will make it simpler to support new types 
> of databases (or fix issues in the SQLProvider implementations) without 
> requiring a new release of Artemis for that.
> If the SQLProvider instance injected in the JDBC store is null, the current 
> code will be executed.
> Does these improvements sound correct?



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


[jira] [Commented] (ARTEMIS-742) replication quorum broken

2016-09-23 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-742:


GitHub user andytaylor opened a pull request:

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

 ARTEMIS-742 - test fixes

https://issues.apache.org/jira/browse/ARTEMIS-742

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

$ git pull https://github.com/andytaylor/activemq-artemis splitbrain

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

https://github.com/apache/activemq-artemis/pull/792.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 #792


commit 4c1d9e2c0f5799477b002a1fb643b8acf554fc4b
Author: Andy Taylor 
Date:   2016-09-23T07:17:56Z

 ARTEMIS-742 = test fixes

https://issues.apache.org/jira/browse/ARTEMIS-742




> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.5.0
>
>




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