date:20170111

[jira] [Resolved] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread Howard Gao (JIRA)


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

Howard Gao resolved ARTEMIS-915.


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

2017-01-11 Thread Alexey Markevich (JIRA)


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

Alexey Markevich updated AMQ-6556:
--
Affects Version/s: 5.14.3

> Support system property proxy settings for HTTP(S) client
> -
>
> Key: AMQ-6556
> URL: https://issues.apache.org/jira/browse/AMQ-6556
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.14.1, 5.14.3
>Reporter: Alexey Markevich
> Attachments: activemq-http.patch
>
>
> Each broker URI should be updated with proxy setting. Using system proxy 
> settings make this transparent.



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

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

2017-01-11 Thread vivikillme (JIRA)


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

vivikillme updated AMQ-6559:

Summary: MultiKahaDBPersistenceAdapter crash  (was: 
MultiKahaDBPersistenceAdapter)

> MultiKahaDBPersistenceAdapter crash
> ---
>
> Key: AMQ-6559
> URL: https://issues.apache.org/jira/browse/AMQ-6559
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.10.0
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> 2.6.32-642.1.1.el6.x86_64
> CentOS release 6.8 (Final)
>Reporter: vivikillme
>
> activemq.log is full of  log like this:
> 2017-01-11 22:35:12,331 | WARN  | Async error occurred:  | 
> org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
> tcp:///10.40.189.204:12188@61616
> java.lang.NullPointerException
>   at 
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.send(Queue.java:733)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:297)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:307)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:152)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:496)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:756)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)[activemq-client-5.10.0.jar:5.10.0]
>   at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
> 2017-01-11 22:35:12,339 | WARN  | Async error occurred:  | 
> org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
> tcp:///10.40.189.179:44900@61616
> java.lang.NullPointerException
>   at 
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
>   at 
>

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF subversion and git services (JIRA)


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

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

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

ARTEMIS-915 WebComponent stopped when backup failback


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-915:


Github user asfgit closed the pull request at:

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


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

2017-01-11 Thread vivikillme (JIRA)


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

vivikillme updated AMQ-6559:

Attachment: zabbix-tcp-info.jpg
activemq.xml

config file & zabbix screenshot

> MultiKahaDBPersistenceAdapter crash
> ---
>
> Key: AMQ-6559
> URL: https://issues.apache.org/jira/browse/AMQ-6559
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.10.0
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> 2.6.32-642.1.1.el6.x86_64
> CentOS release 6.8 (Final)
>Reporter: vivikillme
> Attachments: activemq.xml, zabbix-tcp-info.jpg
>
>
> my activemq  throws Exception and could not work properly。
> activemq.log is full of  log like this:
> 2017-01-11 22:35:12,331 | WARN  | Async error occurred:  | 
> org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
> tcp:///10.40.189.204:12188@61616
> java.lang.NullPointerException
>   at 
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.Queue.send(Queue.java:733)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:297)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:307)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:152)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:496)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:756)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)[activemq-client-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)[activemq-client-5.10.0.jar:5.10.0]
>   at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
> 2017-01-11 22:35:12,339 | WARN  | Async error occurred:  | 
> org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
> tcp:///10.40.189.179:44900@61616
> java.lang.NullPointerException
>   at 
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
>   at 
> org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
>   at 
>

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-915:


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

https://github.com/apache/activemq-artemis/pull/956#discussion_r95721658
  
--- Diff: 
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java
 ---
@@ -170,4 +173,15 @@ private WebAppContext deployWar(String url, String 
warFile, Path warDirectory) t
   handlers.addHandler(webapp);
   return webapp;
}
+
+   @Override
+   public void stop() throws Exception {
--- End diff --

@gaohoward if someone called stop() directly, I would expect it to really 
shutdown.

But I guess it's ok this way.


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Created] (AMQ-6559) MultiKahaDBPersistenceAdapter

2017-01-11 Thread vivikillme (JIRA)

vivikillme created AMQ-6559:
---

 Summary: MultiKahaDBPersistenceAdapter
 Key: AMQ-6559
 URL: https://issues.apache.org/jira/browse/AMQ-6559
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.10.0
 Environment: java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

2.6.32-642.1.1.el6.x86_64

CentOS release 6.8 (Final)
Reporter: vivikillme


activemq.log is full of  log like this:

2017-01-11 22:35:12,331 | WARN  | Async error occurred:  | 
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
tcp:///10.40.189.204:12188@61616
java.lang.NullPointerException
at 
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.send(Queue.java:733)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:297)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:307)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:152)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:496)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:756)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)[activemq-client-5.10.0.jar:5.10.0]
at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
2017-01-11 22:35:12,339 | WARN  | Async error occurred:  | 
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
tcp:///10.40.189.179:44900@61616
java.lang.NullPointerException
at 
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
at

[jira] [Resolved] (ARTEMIS-562) Use 'to' field if sender target is null

2017-01-11 Thread Howard Gao (JIRA)


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

Howard Gao resolved ARTEMIS-562.

Resolution: Fixed

> Use 'to' field if sender target is null
> ---
>
> Key: ARTEMIS-562
> URL: https://issues.apache.org/jira/browse/ARTEMIS-562
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: AMQP, Broker
>Affects Versions: 1.3.0
>Reporter: Gordon Sim
>Assignee: Howard Gao
> Attachments: anonymous-relay.patch, anonymous_sender.py
>
>
> ActiveMQ5 (and other AMQP brokers) support creating a sender with a null 
> target, and then identifying the destination of each messages via the 'to' 
> field. This is very useful in some request-response cases, as it avoids the 
> 'service' having to create and manage senders for every reply-to address. 
> Indeed the qpid-proton request-response examples rely on this.



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

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

2017-01-11 Thread vivikillme (JIRA)


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

vivikillme updated AMQ-6559:

Description: 
my activemq  throws Exception and could not work properly。

activemq.log is full of  log like this:

2017-01-11 22:35:12,331 | WARN  | Async error occurred:  | 
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
tcp:///10.40.189.204:12188@61616
java.lang.NullPointerException
at 
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.send(Queue.java:733)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:297)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:307)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:152)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:496)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:756)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)[activemq-client-5.10.0.jar:5.10.0]
at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
2017-01-11 22:35:12,339 | WARN  | Async error occurred:  | 
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: 
tcp:///10.40.189.179:44900@61616
java.lang.NullPointerException
at 
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.size(MultiKahaDBPersistenceAdapter.java:316)[activemq-kahadb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.StoreUsage.retrieveUsage(StoreUsage.java:51)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.caclPercentUsage(Usage.java:279)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:126)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.usage.Usage.isFull(Usage.java:121)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.checkUsage(Queue.java:959)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:903)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.Queue.send(Queue.java:733)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)[activemq-broker-5.10.0.jar:5.10.0]
at 
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)[activemq-broker-5.10.0.jar:5.10.0]
at

[jira] [Created] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread Howard Gao (JIRA)

Howard Gao created ARTEMIS-915:
--

 Summary: WebComponent stopped when backup failback
 Key: ARTEMIS-915
 URL: https://issues.apache.org/jira/browse/ARTEMIS-915
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.5.1
Reporter: Howard Gao
 Fix For: 1.5.next


In a fail-back scenario, if live is shut down and restart again, the backup 
will stop itself, and so will its webcomponent, which is a web server embedded. 
In that case user will not be able to access the backup via the web interface.

So no matter whether the backup server is becoming live or fail back, the web 
component should be available all the time, until the VM is shutdown.



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

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-915:


GitHub user gaohoward opened a pull request:

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

ARTEMIS-915 WebComponent stopped when backup failback



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

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

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

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






> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-915:


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

https://github.com/apache/activemq-artemis/pull/956#discussion_r95607988
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/core/server/ShutdownAwareComponent.java
 ---
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.server;
+
+/**
+ * A Component that needs to know the stop reason.
+ */
+public interface ShutdownAwareComponent extends ActiveMQComponent {
--- End diff --

I really don't like that name...

What about calling it ServiceComponent

make the method to be called stop(boolean isShutdown)


No need for these integers, and in case you want to keep a parameter, 
please use an enumeration.


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Assigned] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread Howard Gao (JIRA)


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

Howard Gao reassigned ARTEMIS-915:
--

Assignee: Howard Gao

> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Commented] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-914:


GitHub user jbertram opened a pull request:

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

ARTEMIS-914 use defaults for ReplicaPolicy



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

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

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

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


commit 5da9a71c611ebe62a131188a3f1838b0ac10ff19
Author: Justin Bertram 
Date:   2017-01-11T17:40:13Z

ARTEMIS-914 use defaults for ReplicaPolicy




> Max saved replicated journal size on Live node should not be -1
> ---
>
> Key: ARTEMIS-914
> URL: https://issues.apache.org/jira/browse/ARTEMIS-914
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Erich Duda
>Assignee: Justin Bertram
>
> The max-saved-replicated-journal-size on Live node is {{-1}} what can lead to 
> fill the disk by old replicas. The value is hard coded in Artemis code and 
> cannot be changed. I think the default value should be some small number, 
> e.g. 2.
> I hit this issue with Wildfly. There are plans to update Artemis in Wildfly 
> to 1.5.2 version. It would be great if the fix was included in 1.5.2 release. 
> Thanks :)



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

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

2017-01-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-915:


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

https://github.com/apache/activemq-artemis/pull/956#discussion_r95608200
  
--- Diff: 
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java
 ---
@@ -170,4 +173,15 @@ private WebAppContext deployWar(String url, String 
warFile, Path warDirectory) t
   handlers.addHandler(webapp);
   return webapp;
}
+
+   @Override
+   public void stop() throws Exception {
--- End diff --

please, just for completeness.. call stop(true); here (after the method 
name change I asked you)


> WebComponent stopped when backup failback
> -
>
> Key: ARTEMIS-915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-915
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> In a fail-back scenario, if live is shut down and restart again, the backup 
> will stop itself, and so will its webcomponent, which is a web server 
> embedded. In that case user will not be able to access the backup via the web 
> interface.
> So no matter whether the backup server is becoming live or fail back, the web 
> component should be available all the time, until the VM is shutdown.



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

[jira] [Commented] (AMQ-6558) Constant reconnecting after ActiveMQ restart with HTTP Layer

2017-01-11 Thread Timothy Bish (JIRA)


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

Timothy Bish commented on AMQ-6558:
---

This appears to be a duplicate of AMQ-6557

> Constant reconnecting after ActiveMQ restart with HTTP Layer
> 
>
> Key: AMQ-6558
> URL: https://issues.apache.org/jira/browse/AMQ-6558
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.14.1
> Environment: all OSs
>Reporter: Jiri Formanek
>
> ActiveMQ broker reconnects constantly after ActiveMQ restart, when HTTP is 
> used as transport layer.
> Let's consider following simple broker network, where machine A connects to 
> machine B:
> Machine A config:
> {code}
> http://machineB:61617)" 
> name="bridgeToB" />
> {code}
> Machine B config:
> {code}
>  uri="http://0.0.0.0:61617?maximumConnections=1000=104857600"/>
> {code}
> ActiveMQ on machine A is restarted. After the restart the connection to 
> machine B is successfully re-established. But then after 30 seconds the 
> keep-alive mechanism sends a HTTP GET request to machine B and this fails. 
> Keep-alive failure causes the stopping of connection and establishing of new 
> connection, which will be again stopped after 30 seconds. And so on over and 
> over...see the log:
> {noformat}
> 2017-01-11 14:32:19,005 | INFO  | Establishing network connection from 
> vm://localhost?async=false=false to http://machineB:61617 | 
> org.apache.activemq.network.DiscoveryNetworkConnector
> | ActiveMQ Task-1017
> 2017-01-11 14:32:20,726 | INFO  | Broker Servlet supports GZip compression. | 
> org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1017
> 2017-01-11 14:32:20,923 | INFO  | Network connection between 
> vm://localhost#9512 and HTTP Reader http://machineB:61617 (localhost) has 
> been established. | org.apache.activemq.network.DemandFor
> wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
> remoteBroker=HTTP Reader http://machineB:61617, localBroker= 
> vm://localhost#9512
> 2017-01-11 14:32:54,912 | WARN  | Network connection between 
> vm://localhost#9512 and HTTP Reader http://machineB:61617 shutdown due to a 
> remote error: java.io.IOException: Failed to perform GE
> T on: http://machineB:61617 Reason: Read timed out | 
> org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
> Transport: HTTP Reader http://machineB:61617
> 2017-01-11 14:32:54,917 | INFO  | localhost bridge to localhost stopped | 
> org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
> BrokerService[localhost] Task-4377
> 2017-01-11 14:32:55,913 | INFO  | Establishing network connection from 
> vm://localhost?async=false=false to http://machineB:61617 | 
> org.apache.activemq.network.DiscoveryNetworkConnector
> | ActiveMQ Task-1018
> 2017-01-11 14:32:57,642 | INFO  | Broker Servlet supports GZip compression. | 
> org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1018
> 2017-01-11 14:32:57,841 | INFO  | Network connection between 
> vm://localhost#9516 and HTTP Reader http://machineB:61617 (localhost) has 
> been established. | org.apache.activemq.network.DemandFor
> wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
> remoteBroker=HTTP Reader http://machineB:61617, localBroker= 
> vm://localhost#9516
> 2017-01-11 14:33:31,429 | WARN  | Network connection between 
> vm://localhost#9516 and HTTP Reader http://machineB:61617 shutdown due to a 
> remote error: java.io.IOException: Failed to perform GE
> T on: http://machineB:61617 Reason: Read timed out | 
> org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
> Transport: HTTP Reader http://machineB:61617
> 2017-01-11 14:33:31,433 | INFO  | localhost bridge to localhost stopped | 
> org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
> BrokerService[localhost] Task-4390
> 2017-01-11 14:33:32,430 | INFO  | Establishing network connection from 
> vm://localhost?async=false=false to http://machineB:61617 | 
> org.apache.activemq.network.DiscoveryNetworkConnector
> | ActiveMQ Task-1019
> 2017-01-11 14:33:34,157 | INFO  | Broker Servlet supports GZip compression. | 
> org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1019
> 2017-01-11 14:33:34,355 | INFO  | Network connection between 
> vm://localhost#9520 and HTTP Reader http://machineB:61617 (localhost) has 
> been established. | org.apache.activemq.network.DemandFor
> wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
> remoteBroker=HTTP Reader http://machineB:61617, localBroker= 
> vm://localhost#9520
> 2017-01-11 14:34:07,169 | WARN  | Network connection between 
> vm://localhost#9520 and HTTP Reader http://machineB:61617 shutdown due to a 
> remote error: java.io.IOException:

[jira] [Closed] (ARTEMIS-910) Broker does not start if path contains spaces

2017-01-11 Thread clebert suconic (JIRA)


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

clebert suconic closed ARTEMIS-910.
---
   Resolution: Invalid
Fix Version/s: (was: 1.5.next)

> Broker does not start if path contains spaces
> -
>
> Key: ARTEMIS-910
> URL: https://issues.apache.org/jira/browse/ARTEMIS-910
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
> Environment: *nix and windows
>Reporter: Howard Gao
>Assignee: Howard Gao
>
> When install a broker instance in a path that contains spaces the start 
> script doesn't work.



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

[jira] [Commented] (ARTEMIS-911) consumer ack count no increased with individual acknowledge

2017-01-11 Thread Jiri Danek (JIRA)


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

Jiri Danek commented on ARTEMIS-911:


It is now working for me (in git head). Thanks for fixing.

> consumer ack count no increased with individual acknowledge
> ---
>
> Key: ARTEMIS-911
> URL: https://issues.apache.org/jira/browse/ARTEMIS-911
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Commented] (AMQ-6555) Failed to browse topic warnings caused by orphaned expire message tasks in Sceduler

2017-01-11 Thread jack (JIRA)


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

jack commented on AMQ-6555:
---

Thanks Christopher for the swift action to resolve this! It encourages me to 
report more :)

> Failed to browse topic warnings caused by orphaned expire message tasks in 
> Sceduler
> ---
>
> Key: AMQ-6555
> URL: https://issues.apache.org/jira/browse/AMQ-6555
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.14.1
>Reporter: jack
>Assignee: Christopher L. Shannon
> Fix For: 5.15.0, 5.14.4
>
>
> When using a FixedCountSubscriptionRecoveryPolicy on a topic I get millions 
> of warnings when the topic is gc'd after inactivity. The impact is that warn 
> logging has to be turned off which is not ideal. Looking in detail it seems 
> this is caused by a couple of things. Firstly the Topic start method can be 
> invoked twice, once when adding the destination to the RegionBroker and 
> second when the regionBroker is started. 
> That causes the same expireMessagesTask to get scheduled twice which reveals 
> the crux of the problem. The Scheduler allows the same task to be scheduled 
> again in new TimerTasks, even though it will use the same key and ophan any 
> existing (and running) TimerTasks. This is what's happening here. When the 
> topic gets stopped, the orphaned tasks continue to run causing these spurious 
> warnings that clog up the logs.
> My suggestion would be for the scheduler to check if the task has already 
> been registered using a putIfAbsent and fail if it already exists:
> https://github.com/apache/activemq/blob/d9350912984f12356e9d51b0f00b5a28f5cfa58d/activemq-client/src/main/java/org/apache/activemq/thread/Scheduler.java#L42
> These are the warnings we see:
> 2017-01-10 11:36:13,885 [host] Scheduler] - WARN  Topic   
>- Failed to browse Topic: myTopic
> java.lang.NullPointerException
>   at 
> org.apache.activemq.broker.region.policy.FixedCountSubscriptionRecoveryPolicy.browse(FixedCountSubscriptionRecoveryPolicy.java:103)
>   at 
> org.apache.activemq.broker.region.policy.RetainedMessageSubscriptionRecoveryPolicy.browse(RetainedMessageSubscriptionRecoveryPolicy.java:111)
>   at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:677)
>   at org.apache.activemq.broker.region.Topic.access$1(Topic.java:639)
>   at org.apache.activemq.broker.region.Topic$2.run(Topic.java:791)
>   at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
>   at java.util.TimerThread.mainLoop(Timer.java:555)
>   at java.util.TimerThread.run(Timer.java:505



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

[jira] [Created] (AMQ-6556) Support system property proxy settings for HTTP(S) client

2017-01-11 Thread Alexey Markevich (JIRA)

Alexey Markevich created AMQ-6556:
-

 Summary: Support system property proxy settings for HTTP(S) client
 Key: AMQ-6556
 URL: https://issues.apache.org/jira/browse/AMQ-6556
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Transport
Affects Versions: 5.14.1
Reporter: Alexey Markevich
 Attachments: activemq-http.patch

Each broker URI should be updated to take proxy setting. Using system proxy 
settings make this transparent.



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

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

2017-01-11 Thread Alexey Markevich (JIRA)


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

Alexey Markevich updated AMQ-6556:
--
Attachment: activemq-http.patch

> Support system property proxy settings for HTTP(S) client
> -
>
> Key: AMQ-6556
> URL: https://issues.apache.org/jira/browse/AMQ-6556
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.14.1
>Reporter: Alexey Markevich
> Attachments: activemq-http.patch
>
>
> Each broker URI should be updated to take proxy setting. Using system proxy 
> settings make this transparent.



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

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

2017-01-11 Thread Alexey Markevich (JIRA)


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

Alexey Markevich updated AMQ-6556:
--
Description: Each broker URI should be updated with proxy setting. Using 
system proxy settings make this transparent.  (was: Each broker URI should be 
updated to take proxy setting. Using system proxy settings make this 
transparent.)

> Support system property proxy settings for HTTP(S) client
> -
>
> Key: AMQ-6556
> URL: https://issues.apache.org/jira/browse/AMQ-6556
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.14.1
>Reporter: Alexey Markevich
> Attachments: activemq-http.patch
>
>
> Each broker URI should be updated with proxy setting. Using system proxy 
> settings make this transparent.



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

[jira] [Created] (AMQ-6557) Constant reconnecting after ActiveMQ restart with HTTP Layer

2017-01-11 Thread Jiri Formanek (JIRA)

Jiri Formanek created AMQ-6557:
--

 Summary: Constant reconnecting after ActiveMQ restart with HTTP 
Layer
 Key: AMQ-6557
 URL: https://issues.apache.org/jira/browse/AMQ-6557
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker, networkbridge
Affects Versions: 5.14.1
 Environment: Linux openSuse
Reporter: Jiri Formanek


The ActiveMQ broker reconnects constantly to other brokers after restart, when 
HTTP is used as transport layer.

Let's consider following simple broker network, where machine A connects to 
machine B...

Machine A config:
{code}
http://machineB:61617)" 
name="bridgeToB" />
{code}

Machine B config:
{code}
http://0.0.0.0:61617?maximumConnections=1000=104857600"/>
{code}

When ActiveMQ on machine A is restarted, then the connection to machine B is 
successfully re-established after restart, but after 30 seconds, when 
keep-alive mechanism sends a HTTP GET request on machine B, then this fails 
with some java.io.IOException. Then the connection breaks up. It's established 
new connection to machine B and after 30 seconds again fails the keep-alive GET 
request. And so on over and over till ActiveMQ on machine B is restarted.

See logs:

{noformat}
2017-01-11 14:32:19,005 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1017
2017-01-11 14:32:20,726 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1017
2017-01-11 14:32:20,923 | INFO  | Network connection between 
vm://localhost#9512 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9512
2017-01-11 14:32:54,912 | WARN  | Network connection between 
vm://localhost#9512 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:32:54,917 | INFO  | localhost bridge to localhost stopped | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
BrokerService[localhost] Task-4377
2017-01-11 14:32:55,913 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1018
2017-01-11 14:32:57,642 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1018
2017-01-11 14:32:57,841 | INFO  | Network connection between 
vm://localhost#9516 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9516
2017-01-11 14:33:31,429 | WARN  | Network connection between 
vm://localhost#9516 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:33:31,433 | INFO  | localhost bridge to localhost stopped | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
BrokerService[localhost] Task-4390
2017-01-11 14:33:32,430 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1019
2017-01-11 14:33:34,157 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1019
2017-01-11 14:33:34,355 | INFO  | Network connection between 
vm://localhost#9520 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9520
2017-01-11 14:34:07,169 | WARN  | Network connection between 
vm://localhost#9520 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:34:07,175 | INFO  | localhost bridge to localhost stopped |

[jira] [Created] (AMQ-6558) Constant reconnecting after ActiveMQ restart with HTTP Layer

2017-01-11 Thread Jiri Formanek (JIRA)

Jiri Formanek created AMQ-6558:
--

 Summary: Constant reconnecting after ActiveMQ restart with HTTP 
Layer
 Key: AMQ-6558
 URL: https://issues.apache.org/jira/browse/AMQ-6558
 Project: ActiveMQ
  Issue Type: Bug
  Components: networkbridge
Affects Versions: 5.14.1
 Environment: all OSs
Reporter: Jiri Formanek


ActiveMQ broker reconnects constantly after ActiveMQ restart, when HTTP is used 
as transport layer.

Let's consider following simple broker network, where machine A connects to 
machine B:

Machine A config:
{code}
http://machineB:61617)" 
name="bridgeToB" />
{code}

Machine B config:
{code}
http://0.0.0.0:61617?maximumConnections=1000=104857600"/>
{code}

ActiveMQ on machine A is restarted. After the restart the connection to machine 
B is successfully re-established. But then after 30 seconds the keep-alive 
mechanism sends a HTTP GET request to machine B and this fails. Keep-alive 
failure causes the stopping of connection and establishing of new connection, 
which will be again stopped after 30 seconds. And so on over and over...see the 
log:

{noformat}
2017-01-11 14:32:19,005 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1017
2017-01-11 14:32:20,726 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1017
2017-01-11 14:32:20,923 | INFO  | Network connection between 
vm://localhost#9512 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9512
2017-01-11 14:32:54,912 | WARN  | Network connection between 
vm://localhost#9512 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:32:54,917 | INFO  | localhost bridge to localhost stopped | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
BrokerService[localhost] Task-4377
2017-01-11 14:32:55,913 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1018
2017-01-11 14:32:57,642 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1018
2017-01-11 14:32:57,841 | INFO  | Network connection between 
vm://localhost#9516 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9516
2017-01-11 14:33:31,429 | WARN  | Network connection between 
vm://localhost#9516 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:33:31,433 | INFO  | localhost bridge to localhost stopped | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
BrokerService[localhost] Task-4390
2017-01-11 14:33:32,430 | INFO  | Establishing network connection from 
vm://localhost?async=false=false to http://machineB:61617 | 
org.apache.activemq.network.DiscoveryNetworkConnector
| ActiveMQ Task-1019
2017-01-11 14:33:34,157 | INFO  | Broker Servlet supports GZip compression. | 
org.apache.activemq.transport.http.HttpClientTransport | ActiveMQ Task-1019
2017-01-11 14:33:34,355 | INFO  | Network connection between 
vm://localhost#9520 and HTTP Reader http://machineB:61617 (localhost) has been 
established. | org.apache.activemq.network.DemandFor
wardingBridgeSupport | triggerStartAsyncNetworkBridgeCreation: 
remoteBroker=HTTP Reader http://machineB:61617, localBroker= vm://localhost#9520
2017-01-11 14:34:07,169 | WARN  | Network connection between 
vm://localhost#9520 and HTTP Reader http://machineB:61617 shutdown due to a 
remote error: java.io.IOException: Failed to perform GE
T on: http://machineB:61617 Reason: Read timed out | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport: 
HTTP Reader http://machineB:61617
2017-01-11 14:34:07,175 | INFO  | localhost bridge to localhost stopped | 
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ 
BrokerService[localhost] Task-4400
2017-01-11 14:34:08,170 | INFO  |

[jira] [Comment Edited] (ARTEMIS-911) consumer ack count no increased with individual acknowledge

2017-01-11 Thread Jiri Danek (JIRA)


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

Jiri Danek edited comment on ARTEMIS-911 at 1/11/17 5:21 PM:
-

The original scenario is now working for me (with build from git tip). Thanks 
for fixing.


was (Author: jdanek):
It is now working for me (in git head). Thanks for fixing.

> consumer ack count no increased with individual acknowledge
> ---
>
> Key: ARTEMIS-911
> URL: https://issues.apache.org/jira/browse/ARTEMIS-911
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Assigned] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1

2017-01-11 Thread Justin Bertram (JIRA)


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

Justin Bertram reassigned ARTEMIS-914:
--

Assignee: Justin Bertram

> Max saved replicated journal size on Live node should not be -1
> ---
>
> Key: ARTEMIS-914
> URL: https://issues.apache.org/jira/browse/ARTEMIS-914
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
>Reporter: Erich Duda
>Assignee: Justin Bertram
>
> The max-saved-replicated-journal-size on Live node is {{-1}} what can lead to 
> fill the disk by old replicas. The value is hard coded in Artemis code and 
> cannot be changed. I think the default value should be some small number, 
> e.g. 2.
> I hit this issue with Wildfly. There are plans to update Artemis in Wildfly 
> to 1.5.2 version. It would be great if the fix was included in 1.5.2 release. 
> Thanks :)



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

[jira] [Reopened] (ARTEMIS-910) Broker does not start if path contains spaces

2017-01-11 Thread clebert suconic (JIRA)


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

clebert suconic reopened ARTEMIS-910:
-

> Broker does not start if path contains spaces
> -
>
> Key: ARTEMIS-910
> URL: https://issues.apache.org/jira/browse/ARTEMIS-910
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.1
> Environment: *nix and windows
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 1.5.next
>
>
> When install a broker instance in a path that contains spaces the start 
> script doesn't work.



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

[jira] [Resolved] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Created] (AMQ-6559) MultiKahaDBPersistenceAdapter

[jira] [Resolved] (ARTEMIS-562) Use 'to' field if sender target is null

[jira] [Updated] (AMQ-6559) MultiKahaDBPersistenceAdapter crash

[jira] [Created] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Assigned] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Commented] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1

[jira] [Commented] (ARTEMIS-915) WebComponent stopped when backup failback

[jira] [Commented] (AMQ-6558) Constant reconnecting after ActiveMQ restart with HTTP Layer

[jira] [Closed] (ARTEMIS-910) Broker does not start if path contains spaces

[jira] [Commented] (ARTEMIS-911) consumer ack count no increased with individual acknowledge

[jira] [Commented] (AMQ-6555) Failed to browse topic warnings caused by orphaned expire message tasks in Sceduler

[jira] [Created] (AMQ-6556) Support system property proxy settings for HTTP(S) client

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

[jira] [Updated] (AMQ-6556) Support system property proxy settings for HTTP(S) client

[jira] [Created] (AMQ-6557) Constant reconnecting after ActiveMQ restart with HTTP Layer

[jira] [Created] (AMQ-6558) Constant reconnecting after ActiveMQ restart with HTTP Layer

[jira] [Comment Edited] (ARTEMIS-911) consumer ack count no increased with individual acknowledge

[jira] [Assigned] (ARTEMIS-914) Max saved replicated journal size on Live node should not be -1

[jira] [Reopened] (ARTEMIS-910) Broker does not start if path contains spaces

28 matches

Site Navigation

Mail list logo

Footer information