[jira] [Commented] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[Daniel Lindberg (JIRA)]

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

Daniel Lindberg commented on ARTEMIS-807:
-

Sorry, but I fail to understand this answer. 

I got this exception on the original master during failback, not failover 
(semantics I know, but just to be clear). 
As far as I know, I cannot control when a failback happens. I simply start the 
original master, the current master (original slave) will detect this, and 
initiate a failback to the original master. 
The initial failover happened without any issues as far as I can tell.

I don't see how I can 'wait' for the sync to be complete before initiating a 
failback, since I'm not in control of this process. 


> "Error on writing data! File not opened code - 6" on failback
> -
>
> Key: ARTEMIS-807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-807
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Daniel Lindberg
>
> We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
> replication (one master and one slave). We did some failover/failback testing 
> while having light load on the broker (15 messages/second). The failover 
> worked without issues and the flow of messages was uninterupted. 
> However on failback we got several exceptions, and eventually ended up in a 
> state were both master and backup were down, resuling in our application 
> failing.
> I haven't been able to track down the meaning of "File not opened code - 6", 
> but this exception was repeated before we saw 
> "ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]"
> Stack trace below:
> {noformat}
> 14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
> writing data! File not opened code - 6: java.lang.Exception: File not opened
> at 
> org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
>  [artemis-server-1.4.0.jar:1.4.0]
>  
> 14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: 
> ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> 

[jira] [Commented] (ARTEMIS-802) Broker does not throw exception on divert with no name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-802:


GitHub user bayern39 opened a pull request:

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

[ARTEMIS-802] Broker does not throw exception on divert with no name

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

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

$ git pull https://github.com/bayern39/activemq-artemis ARTEMIS-802

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

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


commit 8e6be9182cde422e5a24b681c6acbbba6f0f8b8c
Author: bayern39 
Date:   2016-10-19T01:50:19Z

[ARTEMIS-802] Broker does not throw exception on divert with no name




> Broker does not throw exception on divert with no name
> --
>
> Key: ARTEMIS-802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-802
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>
> Broker does not throw exception on divert with no name instead it simplies 
> ignores the divert and logs an WARN.  This could be easily missed by users, 
> defining a divert in this way is invalid configuration, the broker should 
> throw an exception on boot to make this super clear.



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

[jira] [Commented] (ARTEMIS-786) Store user's password in hash form by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-786:


Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/835
  
ok, let me think about it. Thanks.


> Store user's password in hash form by default
> -
>
> Key: ARTEMIS-786
> URL: https://issues.apache.org/jira/browse/ARTEMIS-786
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.0
>
>
> Artemis use plaintext to store user's password. To enhance security it should 
> be using hash value instead.



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

[jira] [Commented] (ARTEMIS-805) ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to SessionBindingQueryResponseMessage_V3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-805:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/849
  
this commit would actually break stuff pretty badly.

Even .artemis-distribution/src/test/scripts/validate-spaces.sh would be 
broken.


> ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to 
> SessionBindingQueryResponseMessage_V3
> -
>
> Key: ARTEMIS-805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Tomas Hofman
>Assignee: Justin Bertram
>
> If Artemis 1.4.0 standalone JMS client tries to connect to 1.1.0 server then 
> ClassCastException is trhown during creating of producer on session. 
> Client logs following error:
> {code}
> WARN: AMQ212052: Packet 
> PACKET(SessionBindingQueryResponseMessage_V2)[type=-8, channelID=15, 
> packetObject=SessionBindingQueryResponseMessage_V2, exists=true, 
> queueNames=[jms.queue.InQueue], autoCreateJmsQueues=false] was answered out 
> of sequence due to a previous server timeout and it's being ignored
> java.lang.Exception: trace
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:386)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:307)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.addressQuery(ActiveMQSessionContext.java:296)
>   at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.addressQuery(ClientSessionImpl.java:360)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:305)
>   at ProducerTransSession.run(ProducerTransSession.java:53)
> Producer got exception and ended:java.lang.ClassCastException: 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V2
>  cannot be cast to 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V3
> {code}
> This is breaking backward compatibility of JMS clients.
> This was originally reported as JBoss EAP issue: 
> https://issues.jboss.org/browse/JBEAP-6317



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

[jira] [Commented] (ARTEMIS-805) ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to SessionBindingQueryResponseMessage_V3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-805:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/849
  
@jbertram  the failures showing at this build are real. I replicated the 
same issues through a local build.

I would run the whole testsuite for such changes.


> ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to 
> SessionBindingQueryResponseMessage_V3
> -
>
> Key: ARTEMIS-805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Tomas Hofman
>Assignee: Justin Bertram
>
> If Artemis 1.4.0 standalone JMS client tries to connect to 1.1.0 server then 
> ClassCastException is trhown during creating of producer on session. 
> Client logs following error:
> {code}
> WARN: AMQ212052: Packet 
> PACKET(SessionBindingQueryResponseMessage_V2)[type=-8, channelID=15, 
> packetObject=SessionBindingQueryResponseMessage_V2, exists=true, 
> queueNames=[jms.queue.InQueue], autoCreateJmsQueues=false] was answered out 
> of sequence due to a previous server timeout and it's being ignored
> java.lang.Exception: trace
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:386)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:307)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.addressQuery(ActiveMQSessionContext.java:296)
>   at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.addressQuery(ClientSessionImpl.java:360)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:305)
>   at ProducerTransSession.run(ProducerTransSession.java:53)
> Producer got exception and ended:java.lang.ClassCastException: 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V2
>  cannot be cast to 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V3
> {code}
> This is breaking backward compatibility of JMS clients.
> This was originally reported as JBoss EAP issue: 
> https://issues.jboss.org/browse/JBEAP-6317



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

[jira] [Commented] (ARTEMIS-805) ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to SessionBindingQueryResponseMessage_V3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-805:


GitHub user jbertram opened a pull request:

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

ARTEMIS-805 old JMS clients failing on new broker

Old JMS clients are getting a CCE related to 
SessionBindingQueryResponseMessage

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

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

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

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


commit 3f4d7ee7bf6009fb14f9caea0dd2204860a9ddaf
Author: Tomas Hofman 
Date:   2016-10-17T14:31:27Z

ARTEMIS-805 old JMS clients failing on new broker

Old JMS clients are getting a CCE related to 
SessionBindingQueryResponseMessage




> ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to 
> SessionBindingQueryResponseMessage_V3
> -
>
> Key: ARTEMIS-805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Tomas Hofman
>Assignee: Justin Bertram
>
> If Artemis 1.4.0 standalone JMS client tries to connect to 1.1.0 server then 
> ClassCastException is trhown during creating of producer on session. 
> Client logs following error:
> {code}
> WARN: AMQ212052: Packet 
> PACKET(SessionBindingQueryResponseMessage_V2)[type=-8, channelID=15, 
> packetObject=SessionBindingQueryResponseMessage_V2, exists=true, 
> queueNames=[jms.queue.InQueue], autoCreateJmsQueues=false] was answered out 
> of sequence due to a previous server timeout and it's being ignored
> java.lang.Exception: trace
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:386)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:307)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.addressQuery(ActiveMQSessionContext.java:296)
>   at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.addressQuery(ClientSessionImpl.java:360)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:305)
>   at ProducerTransSession.run(ProducerTransSession.java:53)
> Producer got exception and ended:java.lang.ClassCastException: 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V2
>  cannot be cast to 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V3
> {code}
> This is breaking backward compatibility of JMS clients.
> This was originally reported as JBoss EAP issue: 
> https://issues.jboss.org/browse/JBEAP-6317



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

[jira] [Assigned] (ARTEMIS-805) ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to SessionBindingQueryResponseMessage_V3

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-805:
--

Assignee: Justin Bertram

> ClassCastException: SessionBindingQueryResponseMessage_V2 cannot be cast to 
> SessionBindingQueryResponseMessage_V3
> -
>
> Key: ARTEMIS-805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Tomas Hofman
>Assignee: Justin Bertram
>
> If Artemis 1.4.0 standalone JMS client tries to connect to 1.1.0 server then 
> ClassCastException is trhown during creating of producer on session. 
> Client logs following error:
> {code}
> WARN: AMQ212052: Packet 
> PACKET(SessionBindingQueryResponseMessage_V2)[type=-8, channelID=15, 
> packetObject=SessionBindingQueryResponseMessage_V2, exists=true, 
> queueNames=[jms.queue.InQueue], autoCreateJmsQueues=false] was answered out 
> of sequence due to a previous server timeout and it's being ignored
> java.lang.Exception: trace
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:386)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:307)
>   at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.addressQuery(ActiveMQSessionContext.java:296)
>   at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.addressQuery(ClientSessionImpl.java:360)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:305)
>   at ProducerTransSession.run(ProducerTransSession.java:53)
> Producer got exception and ended:java.lang.ClassCastException: 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V2
>  cannot be cast to 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionBindingQueryResponseMessage_V3
> {code}
> This is breaking backward compatibility of JMS clients.
> This was originally reported as JBoss EAP issue: 
> https://issues.jboss.org/browse/JBEAP-6317



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

[jira] [Resolved] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-808.

Resolution: Fixed

> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Resolved] (ARTEMIS-804) Log message id for dropped messages

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-804.

   Resolution: Fixed
Fix Version/s: 1.5.0

> Log message id for dropped messages
> ---
>
> Key: ARTEMIS-804
> URL: https://issues.apache.org/jira/browse/ARTEMIS-804
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.5.0
>
>
> If no dead letter address is configured then message is dropped when max 
> delivery attempts is reached. In this case warning like:
> {code}
>  17:12:09,202 WARN  [org.apache.activemq.artemis.core.server] (Thread-23 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@7e65de0f-1736233410))
>  AMQ222150: Message has exceeded max delivery attempts. No Dead Letter 
> Address configured for queue jms.queue.InQueue so dropping it
> {code}
> is logged. This warning should also contain message id of the dropped message.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
sounds good


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-808:


Github user asfgit closed the pull request at:

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


> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-808 use privileges to stop executor


> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-804) Log message id for dropped messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-804:


Github user asfgit closed the pull request at:

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


> Log message id for dropped messages
> ---
>
> Key: ARTEMIS-804
> URL: https://issues.apache.org/jira/browse/ARTEMIS-804
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
>Priority: Minor
>
> If no dead letter address is configured then message is dropped when max 
> delivery attempts is reached. In this case warning like:
> {code}
>  17:12:09,202 WARN  [org.apache.activemq.artemis.core.server] (Thread-23 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@7e65de0f-1736233410))
>  AMQ222150: Message has exceeded max delivery attempts. No Dead Letter 
> Address configured for queue jms.queue.InQueue so dropping it
> {code}
> is logged. This warning should also contain message id of the dropped message.



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

[jira] [Commented] (ARTEMIS-786) Store user's password in hash form by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-786:


Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/835
  
The whole masking/hashing process still seems like a bit of a jumble to me. 
 To mask a password there's a raw Java command (e.g. "java -cp classPath> 
org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec 
password-to-encode>") and then there's a new command you've added to hash a 
password.  I think it would provide a much better user experience to unify 
both, if possible.


> Store user's password in hash form by default
> -
>
> Key: ARTEMIS-786
> URL: https://issues.apache.org/jira/browse/ARTEMIS-786
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.0
>
>
> Artemis use plaintext to store user's password. To enhance security it should 
> be using hash value instead.



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

[jira] [Assigned] (ARTEMIS-804) Log message id for dropped messages

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-804:
--

Assignee: Justin Bertram

> Log message id for dropped messages
> ---
>
> Key: ARTEMIS-804
> URL: https://issues.apache.org/jira/browse/ARTEMIS-804
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
>Priority: Minor
>
> If no dead letter address is configured then message is dropped when max 
> delivery attempts is reached. In this case warning like:
> {code}
>  17:12:09,202 WARN  [org.apache.activemq.artemis.core.server] (Thread-23 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@7e65de0f-1736233410))
>  AMQ222150: Message has exceeded max delivery attempts. No Dead Letter 
> Address configured for queue jms.queue.InQueue so dropping it
> {code}
> is logged. This warning should also contain message id of the dropped message.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user graben commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
Have to fix a bug introduced by refactoring. I think inner classes are 
looking better than an anonymous one. It might be better to add components to 
ProtocolTrackerCallBackImpl too make it a static class!?


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-808:


Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/847
  
@jmesnil, is this what you're looking for?


> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-808:


GitHub user jbertram opened a pull request:

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

ARTEMIS-808 use privileges to stop executor



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

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

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

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


commit d720c5e47c4282ea323d065dd2b02442270dc72a
Author: jbertram 
Date:   2016-10-18T21:03:59Z

ARTEMIS-808 use privileges to stop executor




> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user graben commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
A bit more this way? IMO I did not see why to change the method to 
addDataSource. It could be only one and this one is a dependency which is 
mandatory for broker startup.


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-782) Add new configuration schema that includes first class Address elements

[ASF subversion and git services (JIRA)]

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

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

Commit 58310fa8553e9d4a6c6433cb4e99b8ea9e53537e in activemq-artemis's branch 
refs/heads/ARTEMIS-780 from [~martyntaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=58310fa ]

ARTEMIS-782 Added configuration elements for new address model


> Add new configuration schema that includes first class Address elements
> ---
>
> Key: ARTEMIS-782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-782
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>




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

[jira] [Assigned] (ARTEMIS-782) Add new configuration schema that includes first class Address elements

[Martyn Taylor (JIRA)]

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

Martyn Taylor reassigned ARTEMIS-782:
-

Assignee: Martyn Taylor

> Add new configuration schema that includes first class Address elements
> ---
>
> Key: ARTEMIS-782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-782
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>




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

[jira] [Closed] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[clebert suconic (JIRA)]

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

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

> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
> Fix For: 1.5.0
>
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Closed] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-807.
---
Resolution: Not A Problem

> "Error on writing data! File not opened code - 6" on failback
> -
>
> Key: ARTEMIS-807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-807
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Daniel Lindberg
>
> We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
> replication (one master and one slave). We did some failover/failback testing 
> while having light load on the broker (15 messages/second). The failover 
> worked without issues and the flow of messages was uninterupted. 
> However on failback we got several exceptions, and eventually ended up in a 
> state were both master and backup were down, resuling in our application 
> failing.
> I haven't been able to track down the meaning of "File not opened code - 6", 
> but this exception was repeated before we saw 
> "ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]"
> Stack trace below:
> {noformat}
> 14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
> writing data! File not opened code - 6: java.lang.Exception: File not opened
> at 
> org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
>  [artemis-server-1.4.0.jar:1.4.0]
>  
> 14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: 
> ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
>  [artemis-server-1.4.0.jar:1.4.0]
>  
> 14:09:13,332 WARN  [org.apache.activemq.artemis.core.client] AMQ212004: 
> Failed to connect to server.
> 14:09:13,343 INFO  [org.apache.activemq.artemis.core.server] AMQ221002: 
> Apache ActiveMQ Artemis Message Broker version 1.4.0 
> [d8756440-9521-11e6-b058-005056be0eea] stopped, uptime 2 minutes
> {noformat}



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

[jira] [Updated] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-803:

Fix Version/s: 1.5.0

> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
> Fix For: 1.5.0
>
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Commented] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-807:
-

When you start a replication backup, the first thing that happens is to sync 
the data.

If you don't wait for the replication to sync you should see this message.  you 
can't do failover while the server is synchronizing.


I will close this JIRA for two reasons:

- first it seems a non issue.
- if that still an issue, like a spurious message caused by a bug, devs will 
need a way to replicate this anyways, hence I'm closing this, ok?

Feel free to open if you provide more information or a way to replicate it.

> "Error on writing data! File not opened code - 6" on failback
> -
>
> Key: ARTEMIS-807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-807
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Daniel Lindberg
>
> We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
> replication (one master and one slave). We did some failover/failback testing 
> while having light load on the broker (15 messages/second). The failover 
> worked without issues and the flow of messages was uninterupted. 
> However on failback we got several exceptions, and eventually ended up in a 
> state were both master and backup were down, resuling in our application 
> failing.
> I haven't been able to track down the meaning of "File not opened code - 6", 
> but this exception was repeated before we saw 
> "ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]"
> Stack trace below:
> {noformat}
> 14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
> writing data! File not opened code - 6: java.lang.Exception: File not opened
> at 
> org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
>  [artemis-journal-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
>  [artemis-server-1.4.0.jar:1.4.0]
>  
> 14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: 
> ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
> Backup Server was not yet in sync with live]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
>  [artemis-server-1.4.0.jar:1.4.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
>  

[jira] [Commented] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-808:
-

[~jmesnil] do you have a Patch?

> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Updated] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-808:

 Priority: Blocker  (was: Critical)
Fix Version/s: 1.5.0

> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Priority: Blocker
> Fix For: 1.5.0
>
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


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

https://github.com/apache/activemq-artemis/pull/839#discussion_r83920395
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/config/storage/FileStorageConfiguration.java
 ---
@@ -29,7 +29,7 @@
 
@Override
public StoreType getStoreType() {
-  return StoreType.DATABASE;
+  return StoreType.FILE;
--- End diff --

@mtaylor this was a bug, right?


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


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

https://github.com/apache/activemq-artemis/pull/839#discussion_r83920218
  
--- Diff: 
artemis-server-osgi/src/main/java/org/apache/activemq/artemis/osgi/ProtocolTrackerCallBack.java
 ---
@@ -25,4 +25,6 @@
void addFactory(ProtocolManagerFactory pmf);
 
void removeFactory(ProtocolManagerFactory pmf);
+
+   void setDataSourceDependency(boolean dataSourceDependency);
--- End diff --

what about renaming this to:

addDataSource(WhateverInformationForTheDatasource);


the callback could then decide what to do.


the best would be to have a class extending ProtocolTrackerCallback:


ServerTrackerCallback extends ProtocolTrackerCallback


And at the caller we would check an instanceof.

Would that be possible with OSGI?



BTW: thanks for rebasing... at least I can comment on these changes now.


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user graben commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
Rebase is done :)


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Created] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[Jeff Mesnil (JIRA)]

Jeff Mesnil created ARTEMIS-808:
---

 Summary: AccessControlException when closing a connection with a 
security manager.
 Key: ARTEMIS-808
 URL: https://issues.apache.org/jira/browse/ARTEMIS-808
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.4.0
Reporter: Jeff Mesnil


We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
security manager closes a JMS connection:

{noformat}
org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
java.security.AccessControlException: WFSM01: Permission check failed 
(permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
"(vfs:/content/test.jar )" of "ModuleClassLoader for 
Module "deployment.test.jar:main" from Service Module Loader")
at 
org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at 
org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at 
java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
at 
java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
at 
org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
at 
org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
{noformat}

I suspect that the change that was made for ARTEMIS-538 must ensure that the 
executor is shutdown in an priviledged block.





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

[jira] [Updated] (ARTEMIS-808) AccessControlException when closing a connection with a security manager.

[Jeff Mesnil (JIRA)]

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

Jeff Mesnil updated ARTEMIS-808:

Priority: Critical  (was: Major)

> AccessControlException when closing a connection with a security manager.
> -
>
> Key: ARTEMIS-808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-808
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>Priority: Critical
>
> We have spotted a regression from Artemis 1.1.x to 1.4.0 when a client with a 
> security manager closes a JMS connection:
> {noformat}
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.lang.RuntimePermission" "modifyThread")" in code source 
> "(vfs:/content/test.jar )" of "ModuleClassLoader for 
> Module "deployment.test.jar:main" from Service Module Loader")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at 
> java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:735)
> at 
> java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1387)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnection.close(ActiveMQConnection.java:366)
> at 
> org.jboss.as.test.smoke.jms.SendToJMSTopicTest.sendMessage(SendToJMSTopicTest.java:113)
> {noformat}
> I suspect that the change that was made for ARTEMIS-538 must ensure that the 
> executor is shutdown in an priviledged block.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
let me think about the class name...


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
@graben can you rebase against master... and push -f at least?


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user graben commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
Well, I think it must be the same callback to avoid the protocol tracker to 
start the broker if the datasource is not bounded yet. It's just another 
"mandatory" dependency. I might rename the class to more general name, but 
separating would end up in a mass.


> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (ARTEMIS-793) Improvement to OSGi integration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-793:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/839
  
@graben  ^^^ (<<< just to send you a notification)



> Improvement to OSGi integration 
> 
>
> Key: ARTEMIS-793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, osgi
>Reporter: Benjamin Graf
> Fix For: 1.5.0
>
>
> ARTEMIS-714 adds ability to configure external DataSource for usage instead 
> of hardcoded driver. This feature should also  be usable in OSGi environments 
> like Karaf.



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

[jira] [Commented] (AMQ-6469) NPE using wss

[Maxence Dunnewind (JIRA)]

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

Maxence Dunnewind commented on AMQ-6469:


Mhh no, by "but basically it seems that stoping wss requests stop this" I mean 
that if I block wss port in firewall, so that no connections happen, then the 
NPE dissapear, so it's likely that this NPE is caused by wss (we also use 
stomp, hence this precision).

We've not identified when this issue occurs, and were not able to reproduce it 
by ourself (we have quiet a lot of traffic). However, it keeps happening quiet 
often (~ 1 per second).
I'm available on IRC (Sp4rKy) if you want some more live debugging.

> NPE using wss
> -
>
> Key: AMQ-6469
> URL: https://issues.apache.org/jira/browse/AMQ-6469
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.0, 5.14.1
> Environment: Debian Jessie 8.5
>Reporter: Maxence Dunnewind
> Attachments: activemq.xml, jetty.xml
>
>
> Enabling wss on activemq generates lot of NPE exceptions. Tested in 5.14.0 
> and 5.14.1 , both produce same result :
> {quote}
> 2016-10-17 17:19:14,041 | WARN  | /stomp | 
> org.eclipse.jetty.servlet.ServletHandler | qtp1200906406-405501
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.ws.jetty9.WSServlet.doGet(WSServlet.java:88)[activemq-http-5.14.1.jar:5.14.1]
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:622)[tomcat-servlet-api-8.0.24.jar:]
> at 
> org.eclipse.jetty.websocket.servlet.WebSocketServlet.service(WebSocketServlet.java:167)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)[tomcat-servlet-api-8.0.24.jar:]
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.Server.handle(Server.java:499)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
> {quote}
> Config file attached, but basically it seems that stoping wss requests stop 
> this.



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

[jira] [Commented] (AMQ-6469) NPE using wss

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon commented on AMQ-6469:
-

What do you mean by stopping requests?  Do you mean closing the web socket 
connection is what causes the error? 

> NPE using wss
> -
>
> Key: AMQ-6469
> URL: https://issues.apache.org/jira/browse/AMQ-6469
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.0, 5.14.1
> Environment: Debian Jessie 8.5
>Reporter: Maxence Dunnewind
> Attachments: activemq.xml, jetty.xml
>
>
> Enabling wss on activemq generates lot of NPE exceptions. Tested in 5.14.0 
> and 5.14.1 , both produce same result :
> {quote}
> 2016-10-17 17:19:14,041 | WARN  | /stomp | 
> org.eclipse.jetty.servlet.ServletHandler | qtp1200906406-405501
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.ws.jetty9.WSServlet.doGet(WSServlet.java:88)[activemq-http-5.14.1.jar:5.14.1]
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:622)[tomcat-servlet-api-8.0.24.jar:]
> at 
> org.eclipse.jetty.websocket.servlet.WebSocketServlet.service(WebSocketServlet.java:167)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)[tomcat-servlet-api-8.0.24.jar:]
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.Server.handle(Server.java:499)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
> {quote}
> Config file attached, but basically it seems that stoping wss requests stop 
> this.



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

[jira] [Updated] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[Daniel Lindberg (JIRA)]

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

Daniel Lindberg updated ARTEMIS-807:

Description: 
We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
replication (one master and one slave). We did some failover/failback testing 
while having light load on the broker (15 messages/second). The failover worked 
without issues and the flow of messages was uninterupted. 

However on failback we got several exceptions, and eventually ended up in a 
state were both master and backup were down, resuling in our application 
failing.

I haven't been able to track down the meaning of "File not opened code - 6", 
but this exception was repeated before we saw 
"ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
Backup Server was not yet in sync with live]"

Stack trace below:
{noformat}
14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
writing data! File not opened code - 6: java.lang.Exception: File not opened
at 
org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure 
in initialisation: ActiveMQIllegalStateException[errorType=ILLEGAL_STATE 
message=AMQ119026: Backup Server was not yet in sync with live]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:09:13,332 WARN  [org.apache.activemq.artemis.core.client] AMQ212004: Failed 
to connect to server.
14:09:13,343 INFO  [org.apache.activemq.artemis.core.server] AMQ221002: Apache 
ActiveMQ Artemis Message Broker version 1.4.0 
[d8756440-9521-11e6-b058-005056be0eea] stopped, uptime 2 minutes
{noformat}

  was:
We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
replication (one master and one slave). We did some failover/failback testing 
while having light load on the broker (15 messages/second). The failover worked 
without issues and the flow of messages was uninterupted. 

However on failback we got several exceptions, and eventually ended up in a 
state were both master and backup were down, resuling in our application 
failing.

I haven't been able to track down the meaning of "File not opened code - 6", 
but this exception was repeated before we saw 
"ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
Backup Server was not yet in sync with live]"

Stack trace below:
{code}
14:07:23,987 WARN  

[jira] [Updated] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[Daniel Lindberg (JIRA)]

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

Daniel Lindberg updated ARTEMIS-807:

Description: 
We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
replication (one master and one slave). We did some failover/failback testing 
while having light load on the broker (15 messages/second). The failover worked 
without issues and the flow of messages was uninterupted. 

However on failback we got several exceptions, and eventually ended up in a 
state were both master and backup were down, resuling in our application 
failing.

I haven't been able to track down the meaning of "File not opened code - 6", 
but this exception was repeated before we saw 
"ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
Backup Server was not yet in sync with live]"

Stack trace below:
{code}
14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
writing data! File not opened code - 6: java.lang.Exception: File not opened
at 
org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure 
in initialisation: ActiveMQIllegalStateException[errorType=ILLEGAL_STATE 
message=AMQ119026: Backup Server was not yet in sync with live]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:09:13,332 WARN  [org.apache.activemq.artemis.core.client] AMQ212004: Failed 
to connect to server.
14:09:13,343 INFO  [org.apache.activemq.artemis.core.server] AMQ221002: Apache 
ActiveMQ Artemis Message Broker version 1.4.0 
[d8756440-9521-11e6-b058-005056be0eea] stopped, uptime 2 minutes{code}

  was:
We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
replication (one master and one slave). We did some failover/failback testing 
while having light load on the broker (15 messages/second). The failover worked 
without issues and the flow of messages was uninterupted. 

However on failback we got several exceptions, and eventually ended up in a 
state were both master and backup were down, resuling in our application 
failing.

I haven't been able to track down the meaning of "File not opened code - 6", 
but this exception was repeated before we saw 
"ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
Backup Server was not yet in sync with live]"

Stack trace below:

14:07:23,987 WARN  

[jira] [Created] (ARTEMIS-807) "Error on writing data! File not opened code - 6" on failback

[Daniel Lindberg (JIRA)]

Daniel Lindberg created ARTEMIS-807:
---

 Summary: "Error on writing data! File not opened code - 6" on 
failback
 Key: ARTEMIS-807
 URL: https://issues.apache.org/jira/browse/ARTEMIS-807
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.4.0
Reporter: Daniel Lindberg


We are running Artemis 1.4.0 on RHEL 7.2 using a master/slave setup using 
replication (one master and one slave). We did some failover/failback testing 
while having light load on the broker (15 messages/second). The failover worked 
without issues and the flow of messages was uninterupted. 

However on failback we got several exceptions, and eventually ended up in a 
state were both master and backup were down, resuling in our application 
failing.

I haven't been able to track down the meaning of "File not opened code - 6", 
but this exception was repeated before we saw 
"ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=AMQ119026: 
Backup Server was not yet in sync with live]"

Stack trace below:

14:07:23,987 WARN  [org.apache.activemq.artemis.journal] AMQ142027: Error on 
writing data! File not opened code - 6: java.lang.Exception: File not opened
at 
org.apache.activemq.artemis.core.io.DummyCallback.onError(DummyCallback.java:36)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$DelegateCallback.onError(AbstractSequentialFile.java:296)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:307)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:277)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFile$LocalBufferObserver.flushBuffer(AbstractSequentialFile.java:324)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:290)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.flush(TimedBuffer.java:262)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.io.AbstractSequentialFileFactory.deactivateBuffer(AbstractSequentialFileFactory.java:156)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.journal.impl.JournalImpl.stop(JournalImpl.java:2121)
 [artemis-journal-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:215)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.stop(JournalStorageManager.java:157)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.replication.ReplicationEndpoint.stop(ReplicationEndpoint.java:339)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stopComponent(ActiveMQServerImpl.java:1038)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:254)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:07:24,005 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure 
in initialisation: ActiveMQIllegalStateException[errorType=ILLEGAL_STATE 
message=AMQ119026: Backup Server was not yet in sync with live]
at 
org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:310)
 [artemis-server-1.4.0.jar:1.4.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2412)
 [artemis-server-1.4.0.jar:1.4.0]
 
14:09:13,332 WARN  [org.apache.activemq.artemis.core.client] AMQ212004: Failed 
to connect to server.
14:09:13,343 INFO  [org.apache.activemq.artemis.core.server] AMQ221002: Apache 
ActiveMQ Artemis Message Broker version 1.4.0 
[d8756440-9521-11e6-b058-005056be0eea] stopped, uptime 2 minutes



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

[jira] [Commented] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-803] Fix colocated backups with http-upgrade acceptor

*  Do not offset ports for Netty connector/acceptor with http-upgrade
enabled.
* Pass the name of the ActiveMQ server to the HTTP request to initiate
the Upgrade so that the HTTP endpoint on the app server can find the
correct ActiveMQ broker that must handle the upgrade.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-803


> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Commented] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-803:


Github user asfgit closed the pull request at:

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


> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Commented] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-803] Fix colocated backups with http-upgrade acceptor

*  Do not offset ports for Netty connector/acceptor with http-upgrade
enabled.
* Pass the name of the ActiveMQ server to the HTTP request to initiate
the Upgrade so that the HTTP endpoint on the app server can find the
correct ActiveMQ broker that must handle the upgrade.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-803


> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Commented] (ARTEMIS-803) Do not offset port for http-upgrade acceptor for colocated backups

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-803:


GitHub user jmesnil opened a pull request:

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

[ARTEMIS-803] Fix colocated backups with http-upgrade acceptor

*  Do not offset ports for Netty connector/acceptor with http-upgrade
enabled.
* Pass the name of the ActiveMQ server to the HTTP request to initiate
the Upgrade so that the HTTP endpoint on the app server can find the
correct ActiveMQ broker that must handle the upgrade.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-803

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

$ git pull https://github.com/jmesnil/activemq-artemis 
ARTEMIS-803_colocated_http-acceptor

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

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


commit 20d06d2db22a32949625c0db9544a8d27e473ba9
Author: Jeff Mesnil 
Date:   2016-10-17T09:42:57Z

[ARTEMIS-803] Fix colocated backups with http-upgrade acceptor

*  Do not offset ports for Netty connector/acceptor with http-upgrade
enabled.
* Pass the name of the ActiveMQ server to the HTTP request to initiate
the Upgrade so that the HTTP endpoint on the app server can find the
correct ActiveMQ broker that must handle the upgrade.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-803




> Do not offset port for http-upgrade acceptor for colocated backups
> --
>
> Key: ARTEMIS-803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-803
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Jeff Mesnil
>
> In our application server, we use an embedded Artemis server with netty 
> acceptors configured to enable HTTP Upgrade.
> This means that the app server is using the HTTP port to negotiate a HTTP 
> upgrade handshake with Artemis client. If the handshake is succesful, we 
> transfer the connection from our HTTP handler to Artemis netty channel.
> This causes issue with colocated backups as Artemis offsets all the ports for 
> the Netty acceptor. If HTTP Upgrade is enabled, the port should not be offset 
> (as it is "owned" by the app server).
> Additionally, with colocated backups we have a single entry point (the app 
> server's HTTP port) that can be used by multiple Artemis server (the main one 
> and any of its colocated backups). When Artemis sends the HTTP request to 
> initiate the upgrade, it should pass the name of the Artemis server that 
> should handle the upgrade so that the app server can delegate the actual 
> handshake to the correct Artemis server.



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

[jira] [Resolved] (AMQ-6470) Remove unused ControlCommand handling in client

[Dejan Bosanac (JIRA)]

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

Dejan Bosanac resolved AMQ-6470.

Resolution: Fixed

> Remove unused ControlCommand handling in client
> ---
>
> Key: AMQ-6470
> URL: https://issues.apache.org/jira/browse/AMQ-6470
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.14.1
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.15.0
>
>
> We still have unnecessary handling for ControlCommand in ActiveMQClient



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

[jira] [Commented] (AMQ-6470) Remove unused ControlCommand handling in client

[ASF subversion and git services (JIRA)]

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

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

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

https://issues.apache.org/jira/browse/AMQ-6470 - Remove unused ControlCommand 
handling in client


> Remove unused ControlCommand handling in client
> ---
>
> Key: AMQ-6470
> URL: https://issues.apache.org/jira/browse/AMQ-6470
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.14.1
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.15.0
>
>
> We still have unnecessary handling for ControlCommand in ActiveMQClient



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

[jira] [Created] (AMQ-6470) Remove unused ControlCommand handling in client

[Dejan Bosanac (JIRA)]

Dejan Bosanac created AMQ-6470:
--

 Summary: Remove unused ControlCommand handling in client
 Key: AMQ-6470
 URL: https://issues.apache.org/jira/browse/AMQ-6470
 Project: ActiveMQ
  Issue Type: Improvement
Affects Versions: 5.14.1
Reporter: Dejan Bosanac
Assignee: Dejan Bosanac
 Fix For: 5.15.0


We still have unnecessary handling for ControlCommand in ActiveMQClient



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

[jira] [Commented] (ARTEMIS-801) Server doesn't support special characters on the path

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-801:


Github user dudaerich commented on the issue:

https://github.com/apache/activemq-artemis/pull/845
  
Hi @clebertsuconic
my intention here was to fix tests which fail in our CI. The path to 
project directory contains '&' characters. Example of path:
```
.../jdk/java18_default/label/RHEL6&_64/...
```
I didn't realize that this could cause problems at more places in the code. 
Using URI to open a file is much better solution than decoding the URL :). 
Thanks for the proper fix, it looks good. I executed the tests with your fix 
and they passed.


> Server doesn't support special characters on the path
> -
>
> Key: ARTEMIS-801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Erich Duda
>Assignee: clebert suconic
> Fix For: 1.5.0
>
>
> If the path to file contains special characters such as '&', the file is not 
> found.
> {code}
> java.nio.file.NoSuchFileException: 
> /mnt/hudson_workspace/workspace/artemis-project-testsuite-matrix-upstream/NATIVES/false/jdk/openjdk1.8_local/label/RHEL6%26%26x86_64/artemis-cli/target/test-classes/broker-reload.xml
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
>   at java.nio.file.Files.newByteChannel(Files.java:361)
>   at java.nio.file.Files.newByteChannel(Files.java:407)
>   at java.nio.file.Files.readAllBytes(Files.java:3152)
>   at 
> org.apache.activemq.cli.test.FileBrokerTest.replacePatternInFile(FileBrokerTest.java:145)
>   at 
> org.apache.activemq.cli.test.FileBrokerTest.testConfigFileReload(FileBrokerTest.java:137)
> {code}



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