[jira] [Commented] (ARTEMIS-1570) SharedNothingBackup does not replicate all journal from live

2017-12-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-1570:
-

Github user shoukunhuai commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
@clebertsuconic just pushed my test for your reference.


> SharedNothingBackup does not replicate all journal from live
> 
>
> Key: ARTEMIS-1570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1570
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
> Environment: i'm running unit test on windows.
>Reporter: shoukun huai
>Priority: Critical
> Attachments: SharedNothingReplicationTest.java
>
>
> I try to test replication when live is in heavy IO load.
> Attached is my junit test.
> The test use a slow message persister to simulate live is busy on IO, so 
> JournalImpl's `appendExecutor` is busy.
> After start live server, send 5 messages each with a property `delay` of 5000 
> ms, then start the backup server, wait until it is replicated. Then send more 
> messages without delay.
> Stop live and backup after all message sent, then check message journal.
> Backup will miss 2 message/journal entry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ARTEMIS-1570) SharedNothingBackup does not replicate all journal from live

2017-12-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-1570:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
@shoukunhuai I thought about developing a byteman test with some rules on 
stopping during the execution, and then releasing it.


> SharedNothingBackup does not replicate all journal from live
> 
>
> Key: ARTEMIS-1570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1570
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
> Environment: i'm running unit test on windows.
>Reporter: shoukun huai
>Priority: Critical
> Attachments: SharedNothingReplicationTest.java
>
>
> I try to test replication when live is in heavy IO load.
> Attached is my junit test.
> The test use a slow message persister to simulate live is busy on IO, so 
> JournalImpl's `appendExecutor` is busy.
> After start live server, send 5 messages each with a property `delay` of 5000 
> ms, then start the backup server, wait until it is replicated. Then send more 
> messages without delay.
> Stop live and backup after all message sent, then check message journal.
> Backup will miss 2 message/journal entry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ARTEMIS-1570) SharedNothingBackup does not replicate all journal from live

2017-12-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-1570:
-

Github user shoukunhuai commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
@clebertsuconic That will be great if we can avoid wait.
Please do not merge, i will push my test.


> SharedNothingBackup does not replicate all journal from live
> 
>
> Key: ARTEMIS-1570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1570
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
> Environment: i'm running unit test on windows.
>Reporter: shoukun huai
>Priority: Critical
> Attachments: SharedNothingReplicationTest.java
>
>
> I try to test replication when live is in heavy IO load.
> Attached is my junit test.
> The test use a slow message persister to simulate live is busy on IO, so 
> JournalImpl's `appendExecutor` is busy.
> After start live server, send 5 messages each with a property `delay` of 5000 
> ms, then start the backup server, wait until it is replicated. Then send more 
> messages without delay.
> Stop live and backup after all message sent, then check message journal.
> Backup will miss 2 message/journal entry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ARTEMIS-1498) [interop] Openwire internal headers should not be part of message properties

2017-12-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-1498:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1684
  
@RaiSaurabh 

look at example methods from
org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage

I'd image you'd want to encode and decode the 
org.apache.activemq.command.Message during persistence and reload.

```
   @Override
   public int getPersistSize() {
  checkBuffer();
  return DataConstants.SIZE_INT + internalPersistSize();
   }

   private int internalPersistSize() {
  return data.array().length;
   }

   @Override
   public void persist(ActiveMQBuffer targetRecord) {
  checkBuffer();
  targetRecord.writeInt(internalPersistSize());
  targetRecord.writeBytes(data.array(), 0, data.array().length );
   }

   @Override
   public void reloadPersistence(ActiveMQBuffer record) {
  int size = record.readInt();
  byte[] recordArray = new byte[size];
  record.readBytes(recordArray);
  this.messagePaylodStart = 0; // whatever was persisted will be sent
  this.data = Unpooled.wrappedBuffer(recordArray);
  this.bufferValid = true;
  this.durable = true; // it's coming from the journal, so it's durable
  parseHeaders();
   }
```


> [interop] Openwire internal headers should not be part of message properties
> 
>
> Key: ARTEMIS-1498
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1498
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
> Environment: interoperability between Openwire -> AMQP/Core
>Reporter: Michal Toth
>Priority: Minor
>
> Sending an empty message from Openwire JMS client to AMQP or Core receiver 
> client shows extra "internal" headers (__HDR_*) in message properties. 
> They should not be there, as these are internal for broker in my opinion.
> Openwire sender
> {noformat}
> $ java  -jar /var/dtests/node_data/clients/aoc7.jar sender  --timeout 5 
> --log-msgs interop --broker tcp://localhost:61616 --address queue_name_\$ 
> --count 1  --conn-username admin --conn-password admin
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False, 
> 'delivery-count': 0, 'id': 
> 'dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1:1:1:1', 
> 'user-id':None, 'address': 'queue_name_$', 'subject': None, 'reply-to': None, 
> 'correlation-id': None, 'content-type': None, 'content-encoding': None, 
> 'absolute-expiry-time': 0, 'creation-time': 1509702974798, 'group-id': None, 
> 'group-sequence': 0, 'reply-to-group-id': None, 'properties': {}, 'content': 
> None, 'type': None}
> {noformat}
> AMQP/Core receiver
> {noformat}
> $ java  -jar /var/dtests/node_data/clients/aac1.jar receiver  --timeout 5 
> --log-msgs interop --broker localhost:5672 --address queue_name_\$ --count 1  
> --conn-username admin --conn-password admin
> Unsupported object type org.apache.qpid.proton.amqp.Binary 
> \x00\x00\x00Jn\x02\xae\x02{\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01\x00\x01
> Unsupported object type org.apache.qpid.proton.amqp.Binary 
> \x00\x00\x00F{\x01+\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False, 
> 'delivery-count': 0, 'id': None, 'user-id': None, 'address': 'queue_name_$', 
> 'subject': None, 'reply-to': None, 'correlation-id': None, 'content-type': 
> None, 'content-encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
> 1509702974798, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
> None, 'properties': {'__HDR_COMMAND_ID': 5, 'JMSXDeliveryCount': 1, 
> '__HDR_ARRIVAL': 0, '__HDR_MESSAGE_ID': 
> \x00\x00\x00Jn\x02\xae\x02{\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01\x00\x01,
>  '__HDR_GROUP_SEQUENCE': 0, '__HDR_PRODUCER_ID': 
> \x00\x00\x00F{\x01+\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01,
>  '__HDR_DROPPABLE': False, '__HDR_BROKER_IN_TIME': 1509702974800}, 'content': 
> None}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ARTEMIS-1570) SharedNothingBackup does not replicate all journal from live

2017-12-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on ARTEMIS-1570:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
How did u find this ? Nice job. 

I will see if I can change the logic to not need the wait. 


Any tests you can share.  


I’m out this week for the Xmas break. Will take a look on next week. Ok ?


> SharedNothingBackup does not replicate all journal from live
> 
>
> Key: ARTEMIS-1570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1570
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
> Environment: i'm running unit test on windows.
>Reporter: shoukun huai
>Priority: Critical
> Attachments: SharedNothingReplicationTest.java
>
>
> I try to test replication when live is in heavy IO load.
> Attached is my junit test.
> The test use a slow message persister to simulate live is busy on IO, so 
> JournalImpl's `appendExecutor` is busy.
> After start live server, send 5 messages each with a property `delay` of 5000 
> ms, then start the backup server, wait until it is replicated. Then send more 
> messages without delay.
> Stop live and backup after all message sent, then check message journal.
> Backup will miss 2 message/journal entry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (AMQ-6870) java.lang.IllegalArgumentException: Invalid connect parameters: {wireFormat.host=localhost}

2017-12-27 Thread Christopher L. Shannon (JIRA)

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

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

> java.lang.IllegalArgumentException: Invalid connect parameters: 
> {wireFormat.host=localhost}
> ---
>
> Key: AMQ-6870
> URL: https://issues.apache.org/jira/browse/AMQ-6870
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Alejandro Fernandez Haro
>
> I want to connect to my broker using STOMP+SSL as because my broker is 
> exposing that protocol:
> {code:xml}
>  uri="stomp+nio+ssl://0.0.0.0:61612?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
> {code}
> The connector is working fine because I'm able to connect to it with a 
> Javascript library and another Ruby one.
> But when using the Java libraries, by applying the connection string 
> {{"stomp+ssl://localhost:61612"}} or 
> {{"ssl://localhost:61612?wireFormat=stomp"}} it fails because of a bug in the 
> StompSslTransportFactory not supporting the field {{wireFormat.host}}.
> An easy way to get the same error is by applying the following config in 
> camel:
> {code:xml}
>  class="org.apache.activemq.ActiveMQConnectionFactory">
> 
> 
> 
> 
> 
> {code}
> The error I'm getting is:
> {code}
> Invalid connect parameters: {wireFormat.host=localhost}
> {code}
> I think it might be related to this piece of code where it enforces the value 
> if it doesn't exist:
> {code:title=org/apache/activemq/transport/TransportFactory.java}
> public Transport doConnect(URI location) throws Exception { 
> try { 
> Map options = new HashMap String>(URISupport.parseParameters(location)); 
> if( !options.containsKey("wireFormat.host") ) { 
> options.put("wireFormat.host", location.getHost()); 
> } 
> WireFormat wf = createWireFormat(options); 
> Transport transport = createTransport(location, wf); 
> Transport rc = configure(transport, wf, options); 
> if (!options.isEmpty()) { 
> throw new IllegalArgumentException("Invalid connect 
> parameters: " + options); 
> } 
> return rc; 
> } catch (URISyntaxException e) { 
> throw IOExceptionSupport.create(e); 
> } 
> } 
> {code}
> Here's another experience from another guy suffering from the same bug: 
> http://activemq.2283324.n4.nabble.com/quot-wireFormat-host-quot-option-for-StompSslTransportFactory-td4685162.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMQ-6870) java.lang.IllegalArgumentException: Invalid connect parameters: {wireFormat.host=localhost}

2017-12-27 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6870:
-

The StompSslTransportFactory class (and other matching factories for AMQP, 
MQTT, etc) exist for the broker side and is not a client side class.  The class 
exists only in the activemq-stomp jar and is not part of the activemq-client 
jar. The broker uses it to create the server side transport in order to handle 
the STOMP protocol on the broker.  It is not intended for use by the client and 
if you try it isn't going to work because it was never designed as a client 
side class.

No one is denying supporting a standard or telling you to use something else 
because we aren't going to fix a bug.  This was closed because as Tim 
mentioned, there is no bug because the ActiveMQ clients only job is to support 
JMS using the native OpenWire protocol.  It does not support any other protocol 
but OpenWire.  If you want to use STOMP then you need to use a STOMP client.  
Just like if you want to use MQTT or AMQP you need to use clients that support 
those protocols.

I think this is pretty clear and I'm closing this again because this is not a 
bug and works as intended.

> java.lang.IllegalArgumentException: Invalid connect parameters: 
> {wireFormat.host=localhost}
> ---
>
> Key: AMQ-6870
> URL: https://issues.apache.org/jira/browse/AMQ-6870
> Project: ActiveMQ
>  Issue Type: Bug
>Reporter: Alejandro Fernandez Haro
>
> I want to connect to my broker using STOMP+SSL as because my broker is 
> exposing that protocol:
> {code:xml}
>  uri="stomp+nio+ssl://0.0.0.0:61612?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
> {code}
> The connector is working fine because I'm able to connect to it with a 
> Javascript library and another Ruby one.
> But when using the Java libraries, by applying the connection string 
> {{"stomp+ssl://localhost:61612"}} or 
> {{"ssl://localhost:61612?wireFormat=stomp"}} it fails because of a bug in the 
> StompSslTransportFactory not supporting the field {{wireFormat.host}}.
> An easy way to get the same error is by applying the following config in 
> camel:
> {code:xml}
>  class="org.apache.activemq.ActiveMQConnectionFactory">
> 
> 
> 
> 
> 
> {code}
> The error I'm getting is:
> {code}
> Invalid connect parameters: {wireFormat.host=localhost}
> {code}
> I think it might be related to this piece of code where it enforces the value 
> if it doesn't exist:
> {code:title=org/apache/activemq/transport/TransportFactory.java}
> public Transport doConnect(URI location) throws Exception { 
> try { 
> Map options = new HashMap String>(URISupport.parseParameters(location)); 
> if( !options.containsKey("wireFormat.host") ) { 
> options.put("wireFormat.host", location.getHost()); 
> } 
> WireFormat wf = createWireFormat(options); 
> Transport transport = createTransport(location, wf); 
> Transport rc = configure(transport, wf, options); 
> if (!options.isEmpty()) { 
> throw new IllegalArgumentException("Invalid connect 
> parameters: " + options); 
> } 
> return rc; 
> } catch (URISyntaxException e) { 
> throw IOExceptionSupport.create(e); 
> } 
> } 
> {code}
> Here's another experience from another guy suffering from the same bug: 
> http://activemq.2283324.n4.nabble.com/quot-wireFormat-host-quot-option-for-StompSslTransportFactory-td4685162.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)