date:20160916

[jira] [Commented] (AMQ-6428) Add methods for sending messages to topics or queues

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


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

ASF GitHub Bot commented on AMQ-6428:
-

GitHub user hqstevenson opened a pull request:

https://github.com/apache/activemq/pull/198

AMQ-6428 - Add methods to EmbeddedActiveMQBroker an ActiveMQ client JUnit 
Rules



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

$ git pull https://github.com/hqstevenson/activemq AMQ-6428

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

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


commit 343e3738b5cffdd6b95cfa257134108105f714c7
Author: Quinn Stevenson 
Date:   2016-09-16T20:59:13Z

Added methods to EmbeddedActiveMQBroker to send messages, as well as JUnit 
Rules for ActiveMQ clients

commit f7b5b901004b90975cb82390684e89df57eaced4
Author: Quinn Stevenson 
Date:   2016-09-16T20:59:47Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/activemq 
into AMQ-6428

commit 7be356017eecf37fa9c4884906e4eda06d8a6f19
Author: Quinn Stevenson 
Date:   2016-09-16T21:07:13Z

Added license header to files




> Add methods for sending messages to topics or queues
> 
>
> Key: AMQ-6428
> URL: https://issues.apache.org/jira/browse/AMQ-6428
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Quinn Stevenson
>Priority: Minor
>
> To simplify testing, the EmbeddedActiveMQBroker (in activemq-junit) should 
> have methods to send messages to topics and queues.



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

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

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


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

ASF GitHub Bot commented on ARTEMIS-735:


Github user bennetelli commented on the issue:

https://github.com/apache/activemq-artemis/pull/780
  
typically I don't do those things with git. Squashing commits and working 
with github pull request is new to me as well. Will do it better in future. I 
promise ;) Thanks for your help :-) Will fix it the next days.


> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



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

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

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


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

ASF GitHub Bot commented on ARTEMIS-735:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/780
  
I see what you did, you changed the title of the PR. you have to change the 
title of the committs.. look at my previous comment.


> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



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

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

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


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

ASF GitHub Bot commented on ARTEMIS-735:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/780
  
You should make JIRA to be part of the commits... the PR name will get lost 
once merged.

do this:


git rebase -i HEAD~2



edit the name of these two commits and include the jira.



git push origin -f



(I don't mean to be teaching you git.. if you know these commands it's just 
a way to communicate, easier in git than english :) )


> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



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

[jira] [Reopened] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic reopened ARTEMIS-735:
-

> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



--
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-16 Thread Timothy Bish (JIRA)


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

Timothy Bish commented on AMQ-6431:
---

Suggest you add to or create a unit tests for this class that can demonstrate 
the issue.

> 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: 王庆焕
>
> 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] [Updated] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-16 Thread Timothy Bish (JIRA)


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

Timothy Bish updated AMQ-6431:
--
Description: 
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));’
   




  was:
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:

 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));   
}

 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:

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;
}
 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));’
   





> 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: 王庆焕
>
> 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] [Created] (AMQ-6431) BitArrayBin doesn't work well with index larger than Integer.MAX_VALUE

2016-09-16 Thread JIRA

王庆焕 created AMQ-6431:


 Summary: 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: 王庆焕


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:

 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));   
}

 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:

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;
}
 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] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

2016-09-16 Thread Jim Gomes (JIRA)


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

Jim Gomes commented on ARTEMIS-732:
---

Yes, changing the script so the 32-bit libraries don't get loaded into the 
64-bit runtime makes this error message go away.

> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic updated ARTEMIS-732:

Priority: Blocker  (was: Major)

I'm making blocker just to make sure I won't forget it on next release.

Blocker on this case means: can't release without it.

> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic updated ARTEMIS-732:

Description: 
Some systems will throw the following message when loading the wrong bit 
alignment:

{noformat}
OpenJDK 64-Bit Server VM warning: You have loaded library
/home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
which might have disabled stack guard. The VM will try to fix the stack guard 
now.
It's highly recommended that you fix the library with 'execstack -c ', 
or link it with '-z noexecstack'
{noformat}

The problem is with the {{exec}} command-line, specifically the 
{{-Djava.library.path}} parameter. It combines both the 32-bit library path and 
the 64-bit library path, but it doesn't actually work.  The script should deal 
with it accordingly to only have the proper  32-bit or 64-bit. All that is 
necessary is to modify the library path to be platform specific, and the error 
condition is resolved. I have attached modified script files (*{{artemis}}* and 
*{{artemis64}}*) that can be used depending on the run-time environment. Here 
are the key differences between the two scripts:

{code:title=32-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"}}
{code}

{code:title=64-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"
{code}


  was:
The artemis launching script located in the bin folder needs to be split into 
two separate scripts: one for 32-bit, and one for 64-bit. The current script 
attempts (but fails) to be run-time adaptive. However, when running on a 64-bit 
environment, the following error is always displayed when it is run:

{noformat}
OpenJDK 64-Bit Server VM warning: You have loaded library
/home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
which might have disabled stack guard. The VM will try to fix the stack guard 
now.
It's highly recommended that you fix the library with 'execstack -c ', 
or link it with '-z noexecstack'
{noformat}

The problem is with the {{exec}} command-line, specifically the 
{{-Djava.library.path}} parameter. It combines both the 32-bit library path and 
the 64-bit library path, but it doesn't actually work.  The script should be 
split into two separate scripts, one for 32-bit and one for 64-bit. All that is 
necessary is to modify the library path to be platform specific, and the error 
condition is resolved. I have attached modified script files (*{{artemis}}* and 
*{{artemis64}}*) that can be used depending on the run-time environment. Here 
are the key differences between the two scripts:

{code:title=32-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"}}
{code}

{code:title=64-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"
{code}



> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic updated ARTEMIS-732:

Summary: Spurious message while loading native libraries in certain envs.  
(was: Need a 64-bit specific launching script)

> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into 
> two separate scripts: one for 32-bit, and one for 64-bit. The current script 
> attempts (but fails) to be run-time adaptive. However, when running on a 
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> be split into two separate scripts, one for 32-bit and one for 64-bit. All 
> that is necessary is to modify the library path to be platform specific, and 
> the error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Comment Edited] (ARTEMIS-732) Need a 64-bit specific launching script

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic edited comment on ARTEMIS-732 at 9/16/16 1:36 PM:
--

Sorry.. it has been a long week for me :) I didn't realize the environment.


I take that if you only use the proper version (64 bit).. this issue would go 
away?


I will rename this JIRA to avoid the spurious message, and deal with it 
accordingly, and also bump the priority to make sure I won't miss it on 1.5.0. 
(or 1.4.1, I have been thinking of 1.4.1 in really short term).


was (Author: clebertsuconic):
Sorry.. it has been a long week for me :) I didn't realize the environment.


I take that if you only use the proper version (64 bit).. this issue would go 
away?


I will rename this JIRA to avoid the spurious message, and deal with it 
accordingly, and also bump the priority to make sure I won't miss it on 1.5.0.

> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into 
> two separate scripts: one for 32-bit, and one for 64-bit. The current script 
> attempts (but fails) to be run-time adaptive. However, when running on a 
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> be split into two separate scripts, one for 32-bit and one for 64-bit. All 
> that is necessary is to modify the library path to be platform specific, and 
> the error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic commented on ARTEMIS-732:
-

Sorry.. it has been a long week for me :) I didn't realize the environment.


I take that if you only use the proper version (64 bit).. this issue would go 
away?


I will rename this JIRA to avoid the spurious message, and deal with it 
accordingly, and also bump the priority to make sure I won't miss it on 1.5.0.

> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into 
> two separate scripts: one for 32-bit, and one for 64-bit. The current script 
> attempts (but fails) to be run-time adaptive. However, when running on a 
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> be split into two separate scripts, one for 32-bit and one for 64-bit. All 
> that is necessary is to modify the library path to be platform specific, and 
> the error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Closed] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

2016-09-16 Thread clebert suconic (JIRA)


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

clebert suconic closed ARTEMIS-735.
---
Resolution: Fixed

> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



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

[jira] [Commented] (AMQ-6424) Duplicate dead letter queues

2016-09-16 Thread Berge Stillingen (JIRA)


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

Berge Stillingen commented on AMQ-6424:
---

Note: A co-worker of mine experienced the same problem with version 5.13.0  - 
using default persistence configuration (Kahadb). 

> Duplicate dead letter queues
> 
>
> Key: AMQ-6424
> URL: https://issues.apache.org/jira/browse/AMQ-6424
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0, 5.13.3, 5.14.0
> Environment: JDK 1.8.0_93 , Windows Server 2012 R2
>Reporter: Berge Stillingen
>  Labels: database, journal, mssql, paging
>
> In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' 
> create extra DLQ-queues holding duplicate messages. 
> Browsing the admin console, you will sometimes see something like this: 
> - DLQ.myEventQueue 
> - DLQ.DLQ.myEventQueue 
> That both hold the samme message ID, eg. 
> ID:ClientABC-61753-1471513949441-1:4:1:3:1   
> The one from DLQ.myEventQueue is a standard entry caused by a client 
> transaction rollback. 
> The (unwanted) one from DLQ.DLQ.myEventQueue has a 
> - dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store 
> for queue://DLQ.myEventQueue
> At some point you can even get a third queue named 
> - DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID 
> and the same dlqDeliveryFailureCause 
> Reproduce: Haven't found a way to provoke the error. It happens occasionally 
> in a semi-active test environment running with Mule 3.6.2. 
> Best guess is that there is some issue with the use of Journaling and 
> synchronization between Kahadb and the MSSQL-database. 
> Configuration can be found at 
> http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml



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

[jira] [Created] (ARTEMIS-735) Refactoring of JUnit Tests

2016-09-16 Thread Bennet Schulz (JIRA)

Bennet Schulz created ARTEMIS-735:
-

 Summary: Refactoring of JUnit Tests
 Key: ARTEMIS-735
 URL: https://issues.apache.org/jira/browse/ARTEMIS-735
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Bennet Schulz


It should be easier to understand what the respective test does and which 
behaviour is expected.



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

[jira] [Updated] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

2016-09-16 Thread Bennet Schulz (JIRA)


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

Bennet Schulz updated ARTEMIS-735:
--
Summary: Refactoring of JUnit Tests in artemis-rest  (was: Refactoring of 
JUnit Tests)

> Refactoring of JUnit Tests in artemis-rest
> --
>
> Key: ARTEMIS-735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-735
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Bennet Schulz
>
> It should be easier to understand what the respective test does and which 
> behaviour is expected.



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

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues using journaling

2016-09-16 Thread Berge Stillingen (JIRA)


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

Berge Stillingen updated AMQ-6424:
--
Affects Version/s: 5.13.0

> Duplicate dead letter queues using journaling
> -
>
> Key: AMQ-6424
> URL: https://issues.apache.org/jira/browse/AMQ-6424
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0, 5.13.3, 5.14.0
> Environment: JDK 1.8.0_93 , Windows Server 2012 R2
>Reporter: Berge Stillingen
>  Labels: database, journal, mssql, paging
>
> In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' 
> create extra DLQ-queues holding duplicate messages. 
> Browsing the admin console, you will sometimes see something like this: 
> - DLQ.myEventQueue 
> - DLQ.DLQ.myEventQueue 
> That both hold the samme message ID, eg. 
> ID:ClientABC-61753-1471513949441-1:4:1:3:1   
> The one from DLQ.myEventQueue is a standard entry caused by a client 
> transaction rollback. 
> The (unwanted) one from DLQ.DLQ.myEventQueue has a 
> - dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store 
> for queue://DLQ.myEventQueue
> At some point you can even get a third queue named 
> - DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID 
> and the same dlqDeliveryFailureCause 
> Reproduce: Haven't found a way to provoke the error. It happens occasionally 
> in a semi-active test environment running with Mule 3.6.2. 
> Best guess is that there is some issue with the use of Journaling and 
> synchronization between Kahadb and the MSSQL-database. 
> Configuration can be found at 
> http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml



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

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues

2016-09-16 Thread Berge Stillingen (JIRA)


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

Berge Stillingen updated AMQ-6424:
--
Summary: Duplicate dead letter queues  (was: Duplicate dead letter queues 
using journaling)

> Duplicate dead letter queues
> 
>
> Key: AMQ-6424
> URL: https://issues.apache.org/jira/browse/AMQ-6424
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0, 5.13.3, 5.14.0
> Environment: JDK 1.8.0_93 , Windows Server 2012 R2
>Reporter: Berge Stillingen
>  Labels: database, journal, mssql, paging
>
> In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' 
> create extra DLQ-queues holding duplicate messages. 
> Browsing the admin console, you will sometimes see something like this: 
> - DLQ.myEventQueue 
> - DLQ.DLQ.myEventQueue 
> That both hold the samme message ID, eg. 
> ID:ClientABC-61753-1471513949441-1:4:1:3:1   
> The one from DLQ.myEventQueue is a standard entry caused by a client 
> transaction rollback. 
> The (unwanted) one from DLQ.DLQ.myEventQueue has a 
> - dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store 
> for queue://DLQ.myEventQueue
> At some point you can even get a third queue named 
> - DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID 
> and the same dlqDeliveryFailureCause 
> Reproduce: Haven't found a way to provoke the error. It happens occasionally 
> in a semi-active test environment running with Mule 3.6.2. 
> Best guess is that there is some issue with the use of Journaling and 
> synchronization between Kahadb and the MSSQL-database. 
> Configuration can be found at 
> http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml



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

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues using journaling

2016-09-16 Thread Berge Stillingen (JIRA)


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

Berge Stillingen updated AMQ-6424:
--
Labels: database journal mssql paging  (was: database journal mssql)

> Duplicate dead letter queues using journaling
> -
>
> Key: AMQ-6424
> URL: https://issues.apache.org/jira/browse/AMQ-6424
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0, 5.13.3, 5.14.0
> Environment: JDK 1.8.0_93 , Windows Server 2012 R2
>Reporter: Berge Stillingen
>  Labels: database, journal, mssql, paging
>
> In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' 
> create extra DLQ-queues holding duplicate messages. 
> Browsing the admin console, you will sometimes see something like this: 
> - DLQ.myEventQueue 
> - DLQ.DLQ.myEventQueue 
> That both hold the samme message ID, eg. 
> ID:ClientABC-61753-1471513949441-1:4:1:3:1   
> The one from DLQ.myEventQueue is a standard entry caused by a client 
> transaction rollback. 
> The (unwanted) one from DLQ.DLQ.myEventQueue has a 
> - dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store 
> for queue://DLQ.myEventQueue
> At some point you can even get a third queue named 
> - DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID 
> and the same dlqDeliveryFailureCause 
> Reproduce: Haven't found a way to provoke the error. It happens occasionally 
> in a semi-active test environment running with Mule 3.6.2. 
> Best guess is that there is some issue with the use of Journaling and 
> synchronization between Kahadb and the MSSQL-database. 
> Configuration can be found at 
> http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml



--
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-16 Thread Daniel Bonnauer (JIRA)


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

Daniel Bonnauer commented on AMQ-6430:
--

Successfully tried to reproduce this Issue using ActiveMQ 5.13.3


> 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
> 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-6428) Add methods for sending messages to topics or queues

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

[jira] [Commented] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

[jira] [Reopened] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

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

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

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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[jira] [Updated] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[jira] [Comment Edited] (ARTEMIS-732) Need a 64-bit specific launching script

[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script

[jira] [Closed] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

[jira] [Commented] (AMQ-6424) Duplicate dead letter queues

[jira] [Created] (ARTEMIS-735) Refactoring of JUnit Tests

[jira] [Updated] (ARTEMIS-735) Refactoring of JUnit Tests in artemis-rest

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues using journaling

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues

[jira] [Updated] (AMQ-6424) Duplicate dead letter queues using journaling

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

22 matches

Site Navigation

Mail list logo

Footer information