[jira] [Work started] (ARTEMIS-756) Add basic CDI integration

2016-09-27 Thread John D. Ament (JIRA)

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

Work on ARTEMIS-756 started by John D. Ament.
-
> Add basic CDI integration
> -
>
> Key: ARTEMIS-756
> URL: https://issues.apache.org/jira/browse/ARTEMIS-756
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.5.0
>
>
> Add basic CDI integration in Artemis as a new module.  As a user, I can 
> include this module and point to my existing Artemis server or launch an 
> embedded one.  



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


[jira] [Created] (ARTEMIS-756) Add basic CDI integration

2016-09-27 Thread John D. Ament (JIRA)
John D. Ament created ARTEMIS-756:
-

 Summary: Add basic CDI integration
 Key: ARTEMIS-756
 URL: https://issues.apache.org/jira/browse/ARTEMIS-756
 Project: ActiveMQ Artemis
  Issue Type: New Feature
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.5.0


Add basic CDI integration in Artemis as a new module.  As a user, I can include 
this module and point to my existing Artemis server or launch an embedded one.  



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


[jira] [Commented] (ARTEMIS-755) Unexpected registered MBeans warning for diverts on server stop

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

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

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

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

ARTEMIS-755 Fix divert MBean warning


> Unexpected registered MBeans warning for diverts on server stop
> ---
>
> Key: ARTEMIS-755
> URL: https://issues.apache.org/jira/browse/ARTEMIS-755
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.5.0
>
>
> On server stop, a warning is issued for unexpected registered MBeans for 
> (apparently) all diverts. For example for the features/standard/divert 
> example:
> server0-out:15:56:42,655 WARN  [org.apache.activemq.artemis.core.server] 
> AMQ222113: On ManagementService stop, there are 2 unexpected registered 
> MBeans: [core.divert.order-divert, core.divert.prices-divert]
> Seems harmless, but would be good to eliminate the warning.



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


[jira] [Resolved] (AMQ-6438) AMQP: Performance improvements and fixes in the Message transformers

2016-09-27 Thread Timothy Bish (JIRA)

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

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

> AMQP: Performance improvements and fixes in the Message transformers
> 
>
> Key: AMQ-6438
> URL: https://issues.apache.org/jira/browse/AMQ-6438
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.14.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.0
>
>
> The JMS Message Transformer seem to have several areas where performance can 
> be improved.  
> Performance numbers on master before updates were made
> {noformat}
> [jms] Total time for 100 cycles of transforms = 14209 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4282 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 7363 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4475 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2468 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 1613 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13861 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5429 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 8523 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4576 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2577 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 646 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time for 100 cycles of transforms = 523 ms  -> 
> [testComplexQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 215 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 474 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 468 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 274 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 436 ms  -> 
> [testBodyOnlyMessage[Transformer->raw]]
> {noformat}
> After updates and fixes.
> {noformat}
> [jms] Total time for 100 cycles of transforms = 10593 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3571 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 6172 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3725 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2202 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 837 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13193 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5172 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 7711 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4061 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2327 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 371 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time for 100 cycles of transforms = 212 ms  -> 
> [testComplexQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 19 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 210 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 205 ms  -> 
> 

[jira] [Commented] (AMQ-6438) AMQP: Performance improvements and fixes in the Message transformers

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

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

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

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

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

Remove redundant tests and clean up a few small nits.

> AMQP: Performance improvements and fixes in the Message transformers
> 
>
> Key: AMQ-6438
> URL: https://issues.apache.org/jira/browse/AMQ-6438
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.14.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.0
>
>
> The JMS Message Transformer seem to have several areas where performance can 
> be improved.  
> Performance numbers on master before updates were made
> {noformat}
> [jms] Total time for 100 cycles of transforms = 14209 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4282 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 7363 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4475 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2468 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 1613 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13861 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5429 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 8523 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4576 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2577 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 646 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time for 100 cycles of transforms = 523 ms  -> 
> [testComplexQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 215 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 474 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 468 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 274 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 436 ms  -> 
> [testBodyOnlyMessage[Transformer->raw]]
> {noformat}
> After updates and fixes.
> {noformat}
> [jms] Total time for 100 cycles of transforms = 10593 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3571 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 6172 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3725 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2202 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 837 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13193 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5172 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 7711 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4061 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2327 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 371 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time for 100 cycles of transforms = 212 ms  -> 
> [testComplexQpidJMSMessage[Transformer->raw]]

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

2016-09-27 Thread William Crowell (JIRA)

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

William Crowell commented on AMQ-6441:
--

I am able to reproduce it like this:

import java.io.File;
import org.junit.Before;
import org.junit.Test;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

public class FileApiTest {
private File mockFile;

@Before
public void setUp() {
mockFile = mock(File.class);
}

@Test
public void test1() {
when(mockFile.getTotalSpace()).thenReturn(9223372036854775807L + 4193L);
long totalSpace = mockFile.getTotalSpace();
//totalSpace will be equal to -9223372036854771616
}
}

> 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-6438) AMQP: Performance improvements and fixes in the Message transformers

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

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

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

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

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

Add a new test for encode / decode validation.  Fix issue where the
internal scheduled message properties were escaping into the outbound
message.

> AMQP: Performance improvements and fixes in the Message transformers
> 
>
> Key: AMQ-6438
> URL: https://issues.apache.org/jira/browse/AMQ-6438
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.14.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.0
>
>
> The JMS Message Transformer seem to have several areas where performance can 
> be improved.  
> Performance numbers on master before updates were made
> {noformat}
> [jms] Total time for 100 cycles of transforms = 14209 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4282 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 7363 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 4475 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2468 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 1613 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13861 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5429 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 8523 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4576 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2577 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 646 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time for 100 cycles of transforms = 523 ms  -> 
> [testComplexQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 215 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 474 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 468 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 274 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->raw]]
> [raw] Total time for 100 cycles of transforms = 436 ms  -> 
> [testBodyOnlyMessage[Transformer->raw]]
> {noformat}
> After updates and fixes.
> {noformat}
> [jms] Total time for 100 cycles of transforms = 10593 ms  -> 
> [testComplexQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3571 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 6172 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 3725 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 2202 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->jms]]
> [jms] Total time for 100 cycles of transforms = 837 ms  -> 
> [testBodyOnlyMessage[Transformer->jms]]
> [native] Total time for 100 cycles of transforms = 13193 ms  -> 
> [testComplexQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 5172 ms  -> 
> [testTypicalQpidJMSMessageOutBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 7711 ms  -> 
> [testTypicalQpidJMSMessage[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 4061 ms  -> 
> [testMessageWithNoPropertiesOrAnnotations[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 2327 ms  -> 
> [testTypicalQpidJMSMessageInBoundOnly[Transformer->native]]
> [native] Total time for 100 cycles of transforms = 371 ms  -> 
> [testBodyOnlyMessage[Transformer->native]]
> [raw] Total time 

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

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

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

Christopher L. Shannon edited comment on AMQ-6441 at 9/27/16 7:27 PM:
--

This should be tested in a unit test regardless so my recommendation is to not 
worry about that and see if you could use something like mockito to mock/spy on 
the File api interface and then you can configure it to return whatever value 
you want (ie 8 EB) to test.  Off the top of my head maybe something like 
mocking out what the getPersistenceAdapter() method returns in BrokerService 
could work so that when the usage checks get the directory to check the size it 
will return your Directory/File mock etc.


was (Author: christopher.l.shannon):
This should be tested in a unit test regardless so my recommendation is to not 
worry about that and see if you could use something like mockito to mock/spy on 
the File api interface and then you can configure it to return whatever value 
you want (ie 8 EB) to test.  Off the top of my head maybe something like 
mocking out out the getPersistenceAdapter() method in BrokerService so that 
when it returns a directory for the usage checks it will return your 
Directory/File mock etc.

> 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] [Assigned] (ARTEMIS-739) Large messages failing with "(Too many open files)"

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram reassigned ARTEMIS-739:
--

Assignee: Justin Bertram

> Large messages failing with "(Too many open files)"
> ---
>
> Key: ARTEMIS-739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-739
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Damien Hollis
>Assignee: Justin Bertram
>Priority: Critical
>
> We are processing a large number of large messages and many of them are being 
> put into the dead-letter queue as part of a transaction rollback.  I suspect 
> that during the rollback the large message is not being released properly and 
> as a result the error below eventually occurs.  This may be a more general 
> issue but so far we have only seen this issue when processing messages 
> successfully (although another person in the team mentioned that there seem 
> to be a lot of large messages hanging around).
> I noted we are not using the latest version, so I'm in the process of 
> creating a new build and I will test with version 1.4 later today or tomorrow.
> {noformat}
> org.apache.activemq.artemis.core.server | AMQ222010: Critical IO Error, 
> shutting
> down the server. file=NIOSequentialFile 
> /var/data/artemis/large-messages/2147660860.msg, 
> message=/var/data/artemis/large-messages/2147660860.msg (Too many open files)
> org.apache.activemq.artemis.api.core.ActiveMQIOErrorException: 
> /var/data/artemis/large-messages/2147660860.msg (Too many open files)
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:101)
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:85)
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl$DecodingContext.open(LargeServerMessageImpl.java:426)
> at 
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl$LargeMessageDeliverer.deliver(ServerConsumerImpl.java:1131)
> at 
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:414)
> at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2464)
> at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:1956)
> at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1500(QueueImpl.java:99)
> at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2695)
> at 
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.FileNotFoundException: 
> /var/data/artemis/large-messages/2147660860.msg (Too many open files)
> at java.io.RandomAccessFile.open0(Native Method)
> at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
> at java.io.RandomAccessFile.(RandomAccessFile.java:243)
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:91)
> ... 12 common frames omitted
> {noformat}



--
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-27 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6441:
-

This should be tested in a unit test regardless so my recommendation is to not 
worry about that and see if you could use something like mockito to mock/spy on 
the File api interface and then you can configure it to return whatever value 
you want (ie 8 EB) to test.  Off the top of my head maybe something like 
mocking out out the getPersistenceAdapter() method in BrokerService so that 
when it returns a directory for the usage checks it will return your 
Directory/File mock etc.

> 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-27 Thread William Crowell (JIRA)

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

William Crowell commented on AMQ-6441:
--

I can work on this, but I do not have an 8 exabyte volume to test this on.  
Does AWS provision volumes like this for no cost?  Or a trial?

> 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-750) Artemis Windows Service Fails to Start

2016-09-27 Thread Jim Gomes (JIRA)

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

Jim Gomes commented on ARTEMIS-750:
---

Considering that ActiveMQ 5.x launcher uses the JAVA_HOME variable, I would say 
that it's better to use that instead of relying on the path.  Here's the 
relevant part from the launcher:

{code}
if "%JAVA_HOME%" == "" goto noJavaHome
if not exist "%JAVA_HOME%\bin\java.exe" goto noJavaHome
if "%_JAVACMD%" == "" set _JAVACMD=%JAVA_HOME%\bin\java.exe
{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
>Assignee: Justin Bertram
>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] [Updated] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

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

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

Christopher L. Shannon updated AMQ-6422:

Fix Version/s: 5.14.1

> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.14.1, 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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


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

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram reassigned ARTEMIS-750:
--

Assignee: Justin Bertram

> 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
>Assignee: Justin Bertram
>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] [Resolved] (ARTEMIS-743) Default the queue address to the queue name

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram resolved ARTEMIS-743.

   Resolution: Fixed
Fix Version/s: 1.5.0

> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
> Fix For: 1.5.0
>
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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


[jira] [Commented] (ARTEMIS-744) Problem to connect in a list of nodes when 1 or more is down.

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram commented on ARTEMIS-744:


Can you provide a reproducible test-case?

> Problem to connect in a list of nodes when 1 or more is down.
> -
>
> Key: ARTEMIS-744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Vinicius Araujo Geraldo
>
> The Artemis' Client when pass the list of nodes, if one is down when consumer 
> try to connect the client thrown an exception and not connect to another 
> nodes.
> Here the code i am using to test:
> TransportConfiguration[] servers = {server1, server2};
> ActiveMQConnectionFactory connectionFactory = 
> ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, servers);
> factory.createConnection(username, password);
> I tried to pass param FailoverOnInitialConnection to ConnectionFactory but 
> inside Implementation this param is discarted.
> Is import that client connect to available nodes and try to reconnect in 
> future to others nodes. 



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


[jira] [Commented] (ARTEMIS-745) Messages sent to a jms topic address are not expiring in temporary queue created via core API

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram commented on ARTEMIS-745:


Can you provide a reproducible test-case?

> Messages sent to a jms topic address are not expiring in temporary queue 
> created via core API
> -
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>
> I am publishing messages to a topic address (jms.topic.).  I set the 
> message expiration to be 2 seconds (publishing via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the  address.  The 
> stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  To investigate slow consumer scenarios, both 
> consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
> count rises, while the MessageCount stays constant with the MessagesAdded 
> count (low number around 5 usually).
> For the core api consumer, however, its queue MessagesAcknowledged attribute 
> count stays at 0, while its MessageCount attribute increases with the 
> MessagesAdded number.  This eventually causes the broker to run out of memory.



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


[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

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

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

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

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

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

Small fix to test and check for zero inflight on successive send to
destination that should have no credit on the registered receiver.


> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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


[jira] [Assigned] (ARTEMIS-745) Messages sent to a jms topic address are not expiring in temporary queue created via core API

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram reassigned ARTEMIS-745:
--

Assignee: Justin Bertram

> Messages sent to a jms topic address are not expiring in temporary queue 
> created via core API
> -
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>Assignee: Justin Bertram
>
> I am publishing messages to a topic address (jms.topic.).  I set the 
> message expiration to be 2 seconds (publishing via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the  address.  The 
> stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  To investigate slow consumer scenarios, both 
> consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
> count rises, while the MessageCount stays constant with the MessagesAdded 
> count (low number around 5 usually).
> For the core api consumer, however, its queue MessagesAcknowledged attribute 
> count stays at 0, while its MessageCount attribute increases with the 
> MessagesAdded number.  This eventually causes the broker to run out of memory.



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


[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

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

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

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

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

https://issues.apache.org/jira/browse/AMQ-6422 - match proton sender view 
credit to prefetchExtension - tracking credit to dispatch delta to track 
additional flow requests. Proton sender layer is distinct from the transport 
layer - they mirror each other


> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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


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

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram commented on ARTEMIS-750:


Current {{artemis-service.xml}} assumes that {{java}} is on your path already 
whereas the modification you've made assumes that {{%JAVA_HOME%}} is defined.  
Both are legitimate assumptions, I think.  I'm not sure one is better than the 
other at this point.

> 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] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

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

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

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

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

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

Adds a split consumer test that uses presettled receivers.


> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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


[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

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

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

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

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

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

Add test for credit grants but no settles for a single receiver.


> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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


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

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram resolved ARTEMIS-747.

   Resolution: Fixed
Fix Version/s: 1.5.0

> 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
> Fix For: 1.5.0
>
>
> 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-755) Unexpected registered MBeans warning for diverts on server stop

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

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

ASF GitHub Bot commented on ARTEMIS-755:


GitHub user jbertram opened a pull request:

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

ARTEMIS-755 Fix divert MBean warning



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

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-755

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

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


commit e53998bf3ba8783d1b2ac6044c6e1863a8ec2dce
Author: jbertram 
Date:   2016-09-27T15:38:43Z

ARTEMIS-755 Fix divert MBean warning




> Unexpected registered MBeans warning for diverts on server stop
> ---
>
> Key: ARTEMIS-755
> URL: https://issues.apache.org/jira/browse/ARTEMIS-755
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.5.0
>
>
> On server stop, a warning is issued for unexpected registered MBeans for 
> (apparently) all diverts. For example for the features/standard/divert 
> example:
> server0-out:15:56:42,655 WARN  [org.apache.activemq.artemis.core.server] 
> AMQ222113: On ManagementService stop, there are 2 unexpected registered 
> MBeans: [core.divert.order-divert, core.divert.prices-divert]
> Seems harmless, but would be good to eliminate the warning.



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


[jira] [Assigned] (ARTEMIS-755) Unexpected registered MBeans warning for diverts on server stop

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram reassigned ARTEMIS-755:
--

Assignee: Justin Bertram

> Unexpected registered MBeans warning for diverts on server stop
> ---
>
> Key: ARTEMIS-755
> URL: https://issues.apache.org/jira/browse/ARTEMIS-755
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.5.0
>
>
> On server stop, a warning is issued for unexpected registered MBeans for 
> (apparently) all diverts. For example for the features/standard/divert 
> example:
> server0-out:15:56:42,655 WARN  [org.apache.activemq.artemis.core.server] 
> AMQ222113: On ManagementService stop, there are 2 unexpected registered 
> MBeans: [core.divert.order-divert, core.divert.prices-divert]
> Seems harmless, but would be good to eliminate the warning.



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


[jira] [Updated] (ARTEMIS-755) Unexpected registered MBeans warning for diverts on server stop

2016-09-27 Thread Justin Bertram (JIRA)

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

Justin Bertram updated ARTEMIS-755:
---
Fix Version/s: 1.5.0

> Unexpected registered MBeans warning for diverts on server stop
> ---
>
> Key: ARTEMIS-755
> URL: https://issues.apache.org/jira/browse/ARTEMIS-755
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.5.0
>
>
> On server stop, a warning is issued for unexpected registered MBeans for 
> (apparently) all diverts. For example for the features/standard/divert 
> example:
> server0-out:15:56:42,655 WARN  [org.apache.activemq.artemis.core.server] 
> AMQ222113: On ManagementService stop, there are 2 unexpected registered 
> MBeans: [core.divert.order-divert, core.divert.prices-divert]
> Seems harmless, but would be good to eliminate the warning.



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


[jira] [Commented] (AMQ-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

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

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

Christopher L. Shannon commented on AMQ-6442:
-

Oops, thanks for closing that, forgot to add the "This closes" to the commit 
message.

> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.1, 5.15.0
>
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


[jira] [Comment Edited] (AMQ-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

2016-09-27 Thread Krzysztof Sobkowiak (JIRA)

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

Krzysztof Sobkowiak edited comment on AMQ-6442 at 9/27/16 1:58 PM:
---

This file is maintained by the Apache ActiveMQ project 
(https://github.com/apache/activemq/blob/master/activemq-karaf/src/main/resources/org.apache.activemq.server-default.cfg).
 Moving this issue to ActiveMQ


was (Author: sobkowiak):
This file is maintained by the Apache ActiveMQ project 
(https://github.com/apache/activemq/blob/master/activemq-karaf/src/main/resources/org.apache.activemq.server-default.cfg).
 Moving this file to ActiveMQ

> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.1, 5.15.0
>
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


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

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

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

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

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

ARTEMIS-737 fixing 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
> Fix For: 1.5.0
>
>
> 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] (AMQ-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

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

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

ASF GitHub Bot commented on AMQ-6442:
-

Github user sobkowiak closed the pull request at:

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


> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.1, 5.15.0
>
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


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

2016-09-27 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 reopened AMQ-6441:
-

Reopening the issue so that a workaround can be done for too large of a file 
size.

> 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-27 Thread Tim Bain (JIRA)

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

Tim Bain commented on AMQ-6441:
---

Let's start with reopening the bug.  No one will contribute code for a bug with 
a Resolution of "Not A Problem."

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

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

Timothy Bish commented on AMQ-6441:
---

Contributions are always welcomed

> 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-27 Thread William Crowell (JIRA)

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

William Crowell commented on AMQ-6441:
--

I agree with Tim.  I would like to see this fixed with the workaround Tim 
proposed.

> 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-27 Thread Tim Bain (JIRA)

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

Tim Bain commented on AMQ-6441:
---

I don't agree that there's nothing we can do, and I think this bug should be 
reopened.

One option would be to explicitly work around this particular use case, by 
assuming that if the long we get back from getTotalSpace() is negative, that 
means the filesystem is plenty big enough to hold the broker's data files.  
Obviously you can construct cases where the overflow will result in a small 
positive number and we'll still give the wrong answer, but the hack would still 
cover anyone with an 8EB filesystem (including the reporter of this bug).  16 
EB or any multiple thereof, however, would be a problem.

Another option would be to provide a config flag that allows you to skip the 
filesystem free space check, eliminating the problem entirely for all 
filesystem sizes when the flag is used.  We should do this at a minimum, 
whether or not we try to do hacks based on negative return values from 
getTotalSpace().

> 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-27 Thread Tim Bain (JIRA)

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

Tim Bain commented on AMQ-6441:
---

An OpenJDK bug was opened about this issue: 
https://bugs.openjdk.java.net/browse/JDK-8162520.  Presumably that means that a 
fix would be part of HotSpot and other non-open JDKs as well.  But since it 
would require an API change, I suspect we wouldn't see it until Java 9, if they 
can convince the Java 9 people to include it there as well.

> 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-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

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

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

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

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

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

Config file org.apache.activemq.server-default.cfg points config to 
${karaf.base}/etc

(cherry picked from commit 132840b09fbf0a071c51d357d12e1325df25)


> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Krzysztof Sobkowiak
>Priority: Minor
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


[jira] [Commented] (AMQ-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

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

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

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

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

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

Merging AMQ-6442


> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Krzysztof Sobkowiak
>Priority: Minor
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


[jira] [Commented] (AMQ-6442) Config file org.apache.activemq.server-default.cfg points config to ${karaf.base}/etc

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

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

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

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

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

Merging AMQ-6442


> Config file org.apache.activemq.server-default.cfg points config to 
> ${karaf.base}/etc
> -
>
> Key: AMQ-6442
> URL: https://issues.apache.org/jira/browse/AMQ-6442
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.14.0, 5.15.0
>Reporter: David Santos
>Assignee: Krzysztof Sobkowiak
>Priority: Minor
>
> Config file {{org.apache.activemq.server-default.cfg}} (created after the 
> first servicemix execution) points the parameter {{config}} to 
> {{$\{karaf.base\}/etc/activemq.xml}} instead of 
> {{$\{karaf.etc\}/activemq.xml}}.
> I cannot provide a patch because I didn't find where this file is generated 
> in the source repo, but it should be trivial.



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


[jira] [Commented] (AMQ-6435) Implement JMX destination query API

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

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

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

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

https://issues.apache.org/jira/browse/AMQ-6435 - destination mbean query api, 
return the right count


> Implement JMX destination query API
> ---
>
> Key: AMQ-6435
> URL: https://issues.apache.org/jira/browse/AMQ-6435
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.14.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.15.0
>
>
> In an environment when there thousands of destinations on the broker, current 
> way of exposing all MBeans and looking into them in the tools does not scale. 
> We need to implement an API that can be used by tools to filter, sort and 
> page destinations in this scenario.



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


[jira] [Commented] (AMQ-6432) Improve 'Failed to load next journal location: null' warning output

2016-09-27 Thread Martin Lichtin (JIRA)

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

Martin Lichtin commented on AMQ-6432:
-

Not seeing the errors all day long, likely just during compaction. We run with 
the default for enableJournalDiskSyncs (true).
One observation, it could be that the issue appears when we purge (via the 
MBean) and reset stats for all destinations.

> Improve 'Failed to load next journal location: null' warning output
> ---
>
> Key: AMQ-6432
> URL: https://issues.apache.org/jira/browse/AMQ-6432
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.14.0
>Reporter: Martin Lichtin
>
> Seeing
> {noformat}
> 2016-09-19 15:11:30,270 | WARN  | ournal Checkpoint Worker | MessageDatabase  
> | 
>emq.store.kahadb.MessageDatabase 2104 | 102 - 
> org.apache.activemq.activemq-osgi - 5.14.0 | 
>Failed to load next journal location: null
> {noformat}
> it'd be great to improve the output in such a case (Journal Checkpoint Worker 
> ).
> Why not show the exception stack (it seems weird to only show the stack when 
> debug level is enabled).



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