[jira] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

2016-01-26 Thread Tristan Leask (JIRA) 

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

Tristan Leask commented on AMQ-5100:


>From my perspective, yes, though it would be good to get a comment from the OP 
>([~jsight]

> PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
> --
>
> Key: AMQ-5100
> URL: https://issues.apache.org/jira/browse/AMQ-5100
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jesse Sightler
>
> I have attempted to configure PKCS11/NSS support in ActiveMQ, however, I am 
> receiving the following exception:
> Caused by: java.io.FileNotFoundException: class path resource [NONE] cannot 
> be opened because it does not exist
> at 
> org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagerKeyStore(SpringSslContext.java:119)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagers(SpringSslContext.java:88)
> at 
> org.apache.activemq.spring.SpringSslContext.afterPropertiesSet(SpringSslContext.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
> ... 40 more
> My configured sslContext for the broker looks like this:
> 
>  keyStore="NONE" keyStoreType="PKCS11" 
> keyStorePassword="password"
> trustStore="/etc/activemqssl/truststore.jks" 
> trustStorePassword="password"
> />
> 
> AFAIK, setting keyStore to "NONE" is the generally accepted way to do with 
> with PKCS11. The code should generate a warning at most for this, but instead 
> I receive the above exception and a failure to load the keystore.
> The activemq code looks like this (in 
> org.apache.activemq.spring.SpringSslContext):
> private KeyStore createKeyManagerKeyStore() throws Exception {
> if( keyStore ==null ) {
> return null;
> }
> KeyStore ks = KeyStore.getInstance(keyStoreType);
> InputStream is=Utils.resourceFromString(keyStore).getInputStream();
> try {
> ks.load(is, keyStorePassword==null? null : 
> keyStorePassword.toCharArray());
> } finally {
> is.close();
> }
> return ks;
> }
> It looks like this should just be setting "is" to null, generating a warning, 
> and then calling ks.load with the null inputstream (the nss library will load 
> the nss files based upon the nss.cfg file).



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


GitHub user l-dobrev opened a pull request:

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

Fix for ARTEMIS-362

Fix for https://issues.apache.org/jira/browse/ARTEMIS-362

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

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

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

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


commit 6c6a237aa276ce7411bcf241495f19d1fff877ee
Author: Lachezar Dobrev 
Date:   2016-01-26T11:03:29Z

Fix for ARTEMIS-362




> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Created] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread Lachezar Dobrev (JIRA) 
Lachezar Dobrev created ARTEMIS-362:
---

 Summary: BroadcastGroupImpl sends datagrams big datagrams full of 
zero bytes
 Key: ARTEMIS-362
 URL: https://issues.apache.org/jira/browse/ARTEMIS-362
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.1.0, 1.0.0, 1.2.0, 1.3.0
 Environment: OS: Linux
JVM: Oracle or OpenJDK, 1.7 or 1.8 
Reporter: Lachezar Dobrev


The BroadcastGroupImpl uses improper buffer handling to generate packages for 
broadcasting to a cluster. This results in sending 4096 byte packages (the size 
of the buffer) full of zero bytes with only about 250-300 bytes actual payload.
This incurs needless weight on any underlying network equipment.
This also may result in loss of service as large packages may be silently 
discarded.



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

[jira] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

2016-01-26 Thread Tristan Leask (JIRA) 

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

Tristan Leask edited comment on AMQ-5100 at 1/26/16 9:32 AM:
-

>From my perspective, yes, though it would be good to get a comment from the OP 
>([~jsight])


was (Author: leaski):
>From my perspective, yes, though it would be good to get a comment from the OP 
>([~jsight]

> PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
> --
>
> Key: AMQ-5100
> URL: https://issues.apache.org/jira/browse/AMQ-5100
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jesse Sightler
>
> I have attempted to configure PKCS11/NSS support in ActiveMQ, however, I am 
> receiving the following exception:
> Caused by: java.io.FileNotFoundException: class path resource [NONE] cannot 
> be opened because it does not exist
> at 
> org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagerKeyStore(SpringSslContext.java:119)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagers(SpringSslContext.java:88)
> at 
> org.apache.activemq.spring.SpringSslContext.afterPropertiesSet(SpringSslContext.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
> ... 40 more
> My configured sslContext for the broker looks like this:
> 
>  keyStore="NONE" keyStoreType="PKCS11" 
> keyStorePassword="password"
> trustStore="/etc/activemqssl/truststore.jks" 
> trustStorePassword="password"
> />
> 
> AFAIK, setting keyStore to "NONE" is the generally accepted way to do with 
> with PKCS11. The code should generate a warning at most for this, but instead 
> I receive the above exception and a failure to load the keystore.
> The activemq code looks like this (in 
> org.apache.activemq.spring.SpringSslContext):
> private KeyStore createKeyManagerKeyStore() throws Exception {
> if( keyStore ==null ) {
> return null;
> }
> KeyStore ks = KeyStore.getInstance(keyStoreType);
> InputStream is=Utils.resourceFromString(keyStore).getInputStream();
> try {
> ks.load(is, keyStorePassword==null? null : 
> keyStorePassword.toCharArray());
> } finally {
> is.close();
> }
> return ks;
> }
> It looks like this should just be setting "is" to null, generating a warning, 
> and then calling ks.load with the null inputstream (the nss library will load 
> the nss files based upon the nss.cfg file).



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-357:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-357 fixing an issue created by my previous commit on this

@jbertram  helped figuring out the growing buffer issue

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

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

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

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


commit 4c22138f5b85ea36e546058bfea02788ab1cf95f
Author: jbertram 
Date:   2016-01-26T18:51:45Z

ARTEMIS-357 test for client buffer mod

commit eb6e042c1c35e5f7de10aa03dd29b45f624e636a
Author: Clebert Suconic 
Date:   2016-01-27T03:30:24Z

ARTEMIS-357 fixing issue with Messages Growing after JMS sends (after my 
last change on ARTEMIS-357)




> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175383216
  
Tests are broken though.. will have to look tomorrow


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175378662
  
Nice work, @clebertsuconic. Glad we squashed this bug.


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175393266
  
fixed the tests


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Created] (AMQ-6144) BrokerService.startTransportConnector should update transportConnectors if JMX is enabled

2016-01-26 Thread Mark Anderson (JIRA) 
Mark Anderson created AMQ-6144:
--

 Summary: BrokerService.startTransportConnector should update 
transportConnectors if JMX is enabled 
 Key: AMQ-6144
 URL: https://issues.apache.org/jira/browse/AMQ-6144
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.13.0
Reporter: Mark Anderson


I am programatically adding and removing TCP connectors to BrokerService where 
JMX is enabled.

I add the connector as follows:
{code}
unmanagedConnector = brokerService.addConnector(connectorUri);
managedConnector = brokerService.startTransportConnector(unmanagedConnector);
{code}

When removing the connector I would have expected the following to work:
{code}
brokerService.removeConnector(managedConnector);
{code}
However this method returns false since transportConnectors does not contain 
the managedConnector and the MBean will not be unregisted.

As a workaround I have to do the following:
{code}
brokerService.removeConnector(unmanagedConnector);
managedConnector.stop();
managedConnector.setBrokerService(null);
{code}
where the removeConnector call will actually unregister the managedConnector 
MBean.

When JMX is enabled should brokerService.startTransportConnector() replace the 
unmanaged connector in the set with the managed connector? Similar to how 
startAllConnectors clears and updates transportConnectors?



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175096224
  
I would like to see a description on the commit about what is being 
changed...

It's fairly common having to do a git log to figure out when things got 
broken... and having to open the JIRA to see what happened is not very 
practical.


I can change the commit description before merging though if you don't 
mind... but if you can ammend with a description such as 

___
ARTEMIS-362 Only sending UDP packets bytes as needed

You can use the next lines to explain things.. etc...
_


Looking at the website (JIRA on this case) should be an extra step to 
eventually look for discussions.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user l-dobrev commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-17508
  
Amended.
How's that?


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175112492
  
much better.. thanks


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175148138
  
It seems nice and clear to be merged.. but I am running the entire 
testsuite on my box before merging this.. .just to be safe.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF subversion and git services (JIRA) 

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

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

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

ARTEMIS-362 Broadcast only filled buffer content.

When publishing server connectors to other cluster members the whole buffer is 
sent.
This fixes ARTEMIS-362 by extracting the filled part of the buffer for 
broadcasting.

Added test case that checks that packet size does not exceed 1500 bytes with 
one connector.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user asfgit closed the pull request at:

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


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

2016-01-26 Thread ASF subversion and git services (JIRA) 

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

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

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

ARTEMIS-362 Broadcast only filled buffer content.

When publishing server connectors to other cluster members the whole buffer is 
sent.
This fixes ARTEMIS-362 by extracting the filled part of the buffer for 
broadcasting.

Added test case that checks that packet size does not exceed 1500 bytes with 
one connector.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (AMQ-6134) ActiveMQ corrupted state when local disk fills up and Queues begin to buffer to KahaDB

2016-01-26 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-6134:
-

fyi https://issues.apache.org/jira/browse/AMQ-6084 in 5.13.1 may also be 
relevant

> ActiveMQ corrupted state when local disk fills up and Queues begin to buffer 
> to KahaDB
> --
>
> Key: AMQ-6134
> URL: https://issues.apache.org/jira/browse/AMQ-6134
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.11.1
>Reporter: Paul Smith
>Priority: Critical
> Attachments: activemq.log, activemq.xml
>
>
> There are already issues reporting this in AMQ-3098 and AMQ-5786 but they 
> have been closed as Incomplete, I've left a comment on 5786 but I fear that 
> it may get lost.
> Fundamentally KahaDB & ActiveMQ do not survive if Queues start filling up and 
> buffering to KahaDB disk when the disk then becomes full because of an 
> external issue (in our case rsyslog).
> Because KahaDB does not pre-allocate space, it seems vunerable to this case.
> I will attach broker logs and Kahadb store during the corrupted state.



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