[jira] [Commented] (AMQ-6133) Message updates can cause message loss on recovery

2016-01-20 Thread Gary Tully (JIRA)

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

Gary Tully commented on AMQ-6133:
-

It should add the message if it cannot be found. It is expected that the 
original gets gced because it is no longer indexed. The update should aim to 
add or replace.

> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Commented] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ

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

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

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

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

ARTEMIS-346 - Add Management send text message functionality similar to ActiveMQ

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


> Add Management send text message functionality similar to ActiveMQ
> --
>
> Key: ARTEMIS-346
> URL: https://issues.apache.org/jira/browse/ARTEMIS-346
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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


[jira] [Commented] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ

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

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

ASF GitHub Bot commented on ARTEMIS-346:


Github user asfgit closed the pull request at:

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


> Add Management send text message functionality similar to ActiveMQ
> --
>
> Key: ARTEMIS-346
> URL: https://issues.apache.org/jira/browse/ARTEMIS-346
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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


[jira] [Commented] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ

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

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

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

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

ARTEMIS-346 - Add Management send text message functionality similar to ActiveMQ

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


> Add Management send text message functionality similar to ActiveMQ
> --
>
> Key: ARTEMIS-346
> URL: https://issues.apache.org/jira/browse/ARTEMIS-346
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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


[jira] [Commented] (AMQ-6133) Message updates can cause message loss on recovery

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

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

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

Commit adc3ba49c2cfb739ad7619a3aa7c5b518de5c996 in activemq's branch 
refs/heads/activemq-5.13.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=adc3ba4 ]

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

Fixing the processing of KahaUpdateMessageCommand to add the message to
the store if it doesn't exist, instead of ignoring it.  This will
prevent message loss in certain cases when the KahaDB index has to be
rebuilt.

(cherry picked from commit b4aa53d806570a4f054dc0af9cb095f13b914153)


> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Commented] (AMQ-6133) Message updates can cause message loss on recovery

2016-01-20 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon commented on AMQ-6133:
-

Thanks for the input Gary, I will create a patch and include Tim's test.

> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Updated] (AMQ-6133) Message updates can cause message loss on recovery

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish updated AMQ-6133:
--
Fix Version/s: 5.14.0
   5.13.1

> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Commented] (AMQ-6133) Message updates can cause message loss on recovery

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

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

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

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

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

Fixing the processing of KahaUpdateMessageCommand to add the message to
the store if it doesn't exist, instead of ignoring it.  This will
prevent message loss in certain cases when the KahaDB index has to be
rebuilt.


> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Resolved] (AMQ-6133) Message updates can cause message loss on recovery

2016-01-20 Thread Christopher L. Shannon (JIRA)

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

Christopher L. Shannon resolved AMQ-6133.
-
Resolution: Fixed
  Assignee: Christopher L. Shannon

Patch and test submitted by [~tabish121] applied to master and 5.13.x.

> Message updates can cause message loss on recovery
> --
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where 
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index 
> with the new location.  This works except that if the index is deleted or 
> corrupted and needs to be rebuilt, the replay process may not be able to 
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage 
> collect the file with the original add command.  So, whatt happens is that 
> during replay when the update command is seen KahaDB rejects it because it 
> can't find the original message if that file has been GC'd.  This happens in 
> the updateIndex method of MessageDatabase on line 1395 where it prints out a 
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after 
> restart is missing messages.



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


[jira] [Closed] (AMQ-6043) CLONE - Occaional hangs on ensureConnectionInfoSent

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-6043.
-
Resolution: Incomplete

There is no indication that there is a client side issue here, appears to be 
working as designed. 

> CLONE - Occaional hangs on ensureConnectionInfoSent
> ---
>
> Key: AMQ-6043
> URL: https://issues.apache.org/jira/browse/AMQ-6043
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.9.1
>Reporter: Gagan
>Assignee: Timothy Bish
> Attachments: blocked-connection-patch3
>
>
> When connecting to the broker, the client occasionally starts to hang. A 
> thread dump reveals:
> {noformat}
> "QuartzScheduler_Worker-7" prio=5 tid=0x0116f190 nid=0x1ce2400 waiting on 
> condition [0xf1fae000..0xf1fafb30]
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767)
>   at 
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:341)
>   at 
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>   at 
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:80)
>   at 
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233)
>   at 
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339)
>   - locked <0x10b9bdf8> (a java.lang.Object)
>   at 
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:298)
>   at org.jencks.amqpool.SessionPool.createSession(SessionPool.java:110)
>   at org.jencks.amqpool.SessionPool.makeObject(SessionPool.java:78)
>   at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974)
>   at org.jencks.amqpool.SessionPool.borrowSession(SessionPool.java:53)
>   at 
> org.jencks.amqpool.ConnectionPool.createSession(ConnectionPool.java:89)
>   at 
> org.jencks.amqpool.XaConnectionPool.createSession(XaConnectionPool.java:51)
>   at 
> org.jencks.amqpool.PooledConnection.createSession(PooledConnection.java:132)
>   at 
> org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
> {noformat}
> Looking closer at the code of {{ensureConnectionInfoSent}} in 
> {{ActiveMQConnection}}, it uses the method:
> {code}
> public Response syncSendPacket(Command command) throws JMSException {
> {code}
> which never times out, possibly causing everything to hang eternally. There 
> does seem to be an identical method that allows for a timeout. 
> {code}
> public Response syncSendPacket(Command command, int timeout) throws 
> JMSException {
> {code}
> should / can ensureConnectionInfoSent use the one with the timeout instead?
> We're using the failover transport:
> failover:(tcp://:54663?wireFormat.maxInactivityDuration=30)?maxReconnectAttempts=10initialReconnectDelay=15000



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


[jira] [Created] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

2016-01-20 Thread clebert suconic (JIRA)
clebert suconic created ARTEMIS-353:
---

 Summary: Calling jmap -heap over artemis will interrupt its 
execution.
 Key: ARTEMIS-353
 URL: https://issues.apache.org/jira/browse/ARTEMIS-353
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 1.3.0


jmap is issuing some weird signals that is interrupting io_getevents call. any 
attempt to use jmap -heap over artemis while using libaio will interrupt the 
server.



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


[jira] [Commented] (AMQ-6043) CLONE - Occaional hangs on ensureConnectionInfoSent

2016-01-20 Thread AbinayaDevarajan (JIRA)

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

AbinayaDevarajan commented on AMQ-6043:
---

Out of office until 16-11-2015


> CLONE - Occaional hangs on ensureConnectionInfoSent
> ---
>
> Key: AMQ-6043
> URL: https://issues.apache.org/jira/browse/AMQ-6043
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.9.1
>Reporter: Gagan
>Assignee: Timothy Bish
> Attachments: blocked-connection-patch3
>
>
> When connecting to the broker, the client occasionally starts to hang. A 
> thread dump reveals:
> {noformat}
> "QuartzScheduler_Worker-7" prio=5 tid=0x0116f190 nid=0x1ce2400 waiting on 
> condition [0xf1fae000..0xf1fafb30]
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767)
>   at 
> java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:341)
>   at 
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>   at 
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:80)
>   at 
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233)
>   at 
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339)
>   - locked <0x10b9bdf8> (a java.lang.Object)
>   at 
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:298)
>   at org.jencks.amqpool.SessionPool.createSession(SessionPool.java:110)
>   at org.jencks.amqpool.SessionPool.makeObject(SessionPool.java:78)
>   at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974)
>   at org.jencks.amqpool.SessionPool.borrowSession(SessionPool.java:53)
>   at 
> org.jencks.amqpool.ConnectionPool.createSession(ConnectionPool.java:89)
>   at 
> org.jencks.amqpool.XaConnectionPool.createSession(XaConnectionPool.java:51)
>   at 
> org.jencks.amqpool.PooledConnection.createSession(PooledConnection.java:132)
>   at 
> org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
> {noformat}
> Looking closer at the code of {{ensureConnectionInfoSent}} in 
> {{ActiveMQConnection}}, it uses the method:
> {code}
> public Response syncSendPacket(Command command) throws JMSException {
> {code}
> which never times out, possibly causing everything to hang eternally. There 
> does seem to be an identical method that allows for a timeout. 
> {code}
> public Response syncSendPacket(Command command, int timeout) throws 
> JMSException {
> {code}
> should / can ensureConnectionInfoSent use the one with the timeout instead?
> We're using the failover transport:
> failover:(tcp://:54663?wireFormat.maxInactivityDuration=30)?maxReconnectAttempts=10initialReconnectDelay=15000



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


[jira] [Closed] (AMQ-5846) High cpu usage if using masterslave discovery in network brokers

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-5846.
-
Resolution: Not A Problem

Given the configuration this appears to be a non-issue, failover and network 
reconnection logic going to kick in here and cause a spike which can be 
controlled by configuring delay and backoff on the failover bits.  

> High cpu usage if using masterslave discovery in network brokers
> 
>
> Key: AMQ-5846
> URL: https://issues.apache.org/jira/browse/AMQ-5846
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: duff qiu
>
> I setup a network brokers with 2 nodes (A, and B)
> In the config, the A and B use masterslave discovery.
> If I start A first, and then start B, I found that the cpu usaging in the 
> machine running A is very high (~100). But The B doens't like that because B 
> can connect to A at the first time.
> I try to use the static:failover way, then the problem is the same 
> (static:failover:()?randomize=false=0)
> But I try to remove the "maxReconnectAttempts=0' or set the value more than 
> 10 , the issue disapeared.
> I think there are some issues on the network transfer impl how to handle the 
> maxReconnectAttempts



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



[jira] [Closed] (AMQ-1243) Multiple WebClient instances

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-1243.
-
Resolution: Unresolved

> Multiple WebClient instances
> 
>
> Key: AMQ-1243
> URL: https://issues.apache.org/jira/browse/AMQ-1243
> Project: ActiveMQ
>  Issue Type: Improvement
> Environment: Using activemq-web-demo as a test for changes in 
> activemq-web while using the 'chat demo'. Patch created from eclipse on mactel
>Reporter: James Alan Shepherd
>Assignee: Dejan Bosanac
>Priority: Minor
> Fix For: AGING_TO_DIE
>
> Attachments: ASF.LICENSE.NOT.GRANTED--patch-trunk-2007-05-04.txt, 
> patch-trunk-2007-05-09.txt
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Just learning about ActiveMQ and noticed, like many before I imagine, that 
> the chat demo doesn't let you use it in different tabs/windows of a browser 
> at once. Well, it runs, but you share the consumers in the WebClient stored 
> in the HttpSession.
> So, why not have multiple WebClients in the Session, one for each 'rendering' 
> of the window, meaning for each instance of amq(.js)?
> So you need a UID in HttpSession for each amq instance.
> You also need to set the amq._pollDelay to something sensible, as polling is 
> done by GET and connections to the server are throttled by the browser.
> Hopefully the attached patch will seem resonable.
> Changes in _amq.js are set to test the new functionality;
> minimal changes to MessageListenerServlet;
> few changes to WebClient;
> added WebClientDirector to direct getting of correct WebClient instance and 
> creating new ones.



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


[jira] [Closed] (AMQ-2394) Ajax does not consume the first message in Firefox

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-2394.
-
Resolution: Won't Fix

WebSocket support can be used instead.

> Ajax does not consume the first message in Firefox
> --
>
> Key: AMQ-2394
> URL: https://issues.apache.org/jira/browse/AMQ-2394
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.3.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.x
>
> Attachments: bug.zip
>
>
> We're trying to use the Jetty continuations MessageListenerService as
> an endpoint for an AJAX app where people get near-realtime updates in
> their browser, where each end user subscribes to their own queue of
> notifications.  (If the user were to leave and then come back, they'd
> get another, brand new queue (with a new, unique name - not sure if
> this is relevant.)
> The plumbing seems to be working pretty well and it's quite a flashy
> bit of work, but we're seeing strange behavior with the very first
> message placed on the queue just disappearing (the
> MessageListenerServlet shows it consumes them but they never come down
> the pipe to the browser over HTTP - or maybe they're being sent to a
> different client or something?).  Sometimes none of the subsequent
> messages ever show up on the client, other times everything works as
> expected.
> We tried unsuccessfully to figure out the cause of the problem,
> because it's sporadic, but it seems to be at least somewhat related to
> http sessions (a cleanly wiped firefox will work great - but then
> repeating the test in the same firefox usually doesn't work) and for
> whatever reason safari seems to work OK whether its cache has been
> cleared or not.  Since there's a difference between web browsers the
> obvious implication is that something is messed up client-side but
> we're having a real hard time figuring out what that could be - no JS
> exceptions or errors, etc, so we've tried messing with all kinds of
> caching to no avail.  This is activemq 5.2.0.  I attached two files,
> one is the debug output from a working session (with safari) and one
> from a non-working session with firefox - the events seem to all show
> up in the logs OK, but for whatever reason they don't make it to the
> browser.
> --
> A simple case to demonstrate, consisting of an html page
> with JS that subscribes to a random queue, the _amq js file, and
> prototype.js.
> Refreshing the page (and therefore subscribing to a new random queue)
> does not seem to work in firefox, but does work in safari.  any ideas
> why that is?
> To run the demo, unzip the attached zip file into the /demo directory
> of the activemq project, and then hit http://localhost:8161/demo/bug/
> in firefox/safari - add things to the queue from the activemq admin
> console.



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


[jira] [Closed] (AMQ-5786) ActiveMQ failed to start with KahaDB reporting corrupt journal records and throwing NegativeArraySizeException

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-5786.
-
Resolution: Incomplete

Without more information there is little that can be done here, we'd need 
broker logs and if possible a test that can reproduce the situation or a copy 
of the faulty index / journal to determine what might have gone wrong.

> ActiveMQ failed to start with KahaDB reporting corrupt journal records and 
> throwing NegativeArraySizeException
> --
>
> Key: AMQ-5786
> URL: https://issues.apache.org/jira/browse/AMQ-5786
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.11.1
> Environment: Karaf 3.0.3
>Reporter: Martin Lichtin
>Priority: Critical
>
> ActiveMQ failed to start up, with the following information:
> {noformat}
> 2015-05-20 14:23:21,709 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 5504795..5505130
> 2015-05-20 14:23:21,725 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 5611475..5612818
> 2015-05-20 14:23:21,749 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 6139835..6140254
> 2015-05-20 14:23:21,756 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 6246179..6247270
> 2015-05-20 14:23:21,765 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 6512519..6520426
> 2015-05-20 14:23:21,789 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 7606018..7627848
> 2015-05-20 14:23:21,794 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 7630473..7650409
> 2015-05-20 14:23:21,796 | INFO  | apache.activemq.server]) | Journal  
> | tore.kahadb.disk.journal.Journal  219 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Corrupt journal records found in 
> 'activemq/kahadb/db-1.log' between offsets: 7650488..7703243
> 2015-05-20 14:23:22,065 | INFO  | apache.activemq.server]) | MessageDatabase  
> | .kahadb.MessageDatabase$Metadata  168 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | KahaDB is version 5
> 2015-05-20 14:23:22,188 | INFO  | apache.activemq.server]) | MessageDatabase  
> | emq.store.kahadb.MessageDatabase  603 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Recovering from the journal ...
> 2015-05-20 14:23:22,188 | ERROR | apache.activemq.server]) | BrokerService
> | he.activemq.broker.BrokerService  609 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Failed to start Apache ActiveMQ 
> ([broker-amq, null], java.io.IOException: Invalid location: 1:6516763, : 
> java.lang.NegativeArraySizeException)
> 2015-05-20 14:23:22,189 | INFO  | apache.activemq.server]) | BrokerService
> | he.activemq.broker.BrokerService  758 | 105 - 
> org.apache.activemq.activemq-osgi - 5.11.1 | Apache ActiveMQ 5.11.1 
> (broker-amq, null) is shutting down
> 2015-05-20 14:23:22,194 | INFO  | apache.activemq.server]) | 
> TransportConnector   | tivemq.broker.TransportConnector  291 | 
> 105 - org.apache.activemq.activemq-osgi - 5.11.1 | Connector openwire stopped
> 2015-05-20 14:23:22,372 | INFO  | apache.activemq.server]) | 
> JobSchedulerStoreImpl| .scheduler.JobSchedulerStoreImpl  259 | 
> 105 - org.apache.activemq.activemq-osgi - 5.11.1 | JobSchedulerStore: 
> activemq/broker-amq/scheduler stopped.
> 2015-05-20 14:23:22,372 | INFO  | apache.activemq.server]) | 

[jira] [Commented] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

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

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

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

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

ARTEMIS-353 retrying after interrupts on the native layer because of jmap 
issuing weird interrupts

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


> Calling jmap -heap over artemis will interrupt its execution.
> -
>
> Key: ARTEMIS-353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-353
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> jmap is issuing some weird signals that is interrupting io_getevents call. 
> any attempt to use jmap -heap over artemis while using libaio will interrupt 
> the server.



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


[jira] [Commented] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

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

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

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

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

ARTEMIS-353 retrying after interrupts on the native layer because of jmap 
issuing weird interrupts

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


> Calling jmap -heap over artemis will interrupt its execution.
> -
>
> Key: ARTEMIS-353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-353
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> jmap is issuing some weird signals that is interrupting io_getevents call. 
> any attempt to use jmap -heap over artemis while using libaio will interrupt 
> the server.



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


[jira] [Closed] (AMQ-5663) Memory leak in message batching

2016-01-20 Thread Timothy Bish (JIRA)

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

Timothy Bish closed AMQ-5663.
-
Resolution: Incomplete

No test case provided to enable an analysis of the reported leak. 

> Memory leak in message batching
> ---
>
> Key: AMQ-5663
> URL: https://issues.apache.org/jira/browse/AMQ-5663
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.10.0
>Reporter: Jaroslav Sedlacek
>
> Memory leak in persistent message batching 
> (Queue.messages.persistent.batchList) caused by inconsistent "cacheEnabled" 
> flag handling.
> When AMQ is started and queue has more messages then 
> maxPageSize/maxExpirePageSize/maxBrowsePageSize, then cacheEnabled flag stays 
> "false" and no additional message is stored in batchList.
> If queue has less messages than that, cacheEnabled is set to "true" and it is 
> set to false only when AMQ has no more space (see 
> AbstractPendingMessageCursor.hasSpace() - by default 70% of heap). It means 
> batchList can grow significantly in this case.
> This behaviour was noticed on DLQ kind of queue with no consumer when a big 
> bunch of messages was added and it caused OOM.



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


[jira] [Closed] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

2016-01-20 Thread clebert suconic (JIRA)

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

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

> Calling jmap -heap over artemis will interrupt its execution.
> -
>
> Key: ARTEMIS-353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-353
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> jmap is issuing some weird signals that is interrupting io_getevents call. 
> any attempt to use jmap -heap over artemis while using libaio will interrupt 
> the server.



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


[jira] [Commented] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

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

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

ASF GitHub Bot commented on ARTEMIS-353:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-353 retrying after interrupts on the native layer



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

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

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

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


commit 2af34a0a53fced144221e437999eadce8a30efe5
Author: Clebert Suconic 
Date:   2016-01-20T19:07:47Z

ARTEMIS-353 retrying after interrupts on the native layer because of jmap 
issuing weird interrupts

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




> Calling jmap -heap over artemis will interrupt its execution.
> -
>
> Key: ARTEMIS-353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-353
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> jmap is issuing some weird signals that is interrupting io_getevents call. 
> any attempt to use jmap -heap over artemis while using libaio will interrupt 
> the server.



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


[jira] [Commented] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ

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

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

ASF GitHub Bot commented on ARTEMIS-346:


GitHub user andytaylor opened a pull request:

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

ARTEMIS-346 - Add Management send text message functionality similar …

…to ActiveMQ

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

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

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

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

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


commit 98a91a0e20c1040298c2df4ec8e8b2b12d53440b
Author: Andy Taylor 
Date:   2016-01-15T13:42:47Z

ARTEMIS-346 - Add Management send text message functionality similar to 
ActiveMQ

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




> Add Management send text message functionality similar to ActiveMQ
> --
>
> Key: ARTEMIS-346
> URL: https://issues.apache.org/jira/browse/ARTEMIS-346
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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


[jira] [Commented] (AMQ-5702) REST production of message bodies can result in IllegalStateException: STREAMED (same as AMQ-5579)

2016-01-20 Thread Andre Gomes Lamas Otero (JIRA)

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

Andre Gomes Lamas Otero commented on AMQ-5702:
--

Hi!

Have you tried the solution given at documentation 
(https://cwiki.apache.org/confluence/display/ACTIVEMQ/REST) ?

On your GitHub code you set 

If strMethod = "POST" Then
  objWinHttp.SetRequestHeader "Content-type", _
"application/x-www-form-urlencoded"
 End If

on the Wiki this issue is addressed by setting the header as:

"Content-Type: text/plain" 


Regards,
André

> REST production of message bodies can result in IllegalStateException: 
> STREAMED (same as AMQ-5579)
> --
>
> Key: AMQ-5702
> URL: https://issues.apache.org/jira/browse/AMQ-5702
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 5.10.0
> Environment: Windows 8.1 64bit
>Reporter: J G
>
> I am working on a project to use Apache ActiveMQ with a RESTful interface. 
> It's a cross platform error logging project, so code written in C++, Java, 
> VBA, Perl or indeed anything that can access an URL can then report issues. 
> The point is, we DO NOT deploy any libraries - we simply use the native 
> implementations within the language to access an URL. The HTTP message body 
> then contains the details of the error - who, what, when, what line of code 
> and so on.
> The piece I am working on is a port of an MSMQ implementation (you can a 
> simpllified implementation of the MSMQ version on this 
> http://blog.alignment-systems.com/2015/03/excel-vba-industrialisationpart-seven.html
>  and on github at https://github.com/JohnGreenan/7_ExcelVBE) 
> So, I can access Apache Active MQ from a Windows PC using the 
> WinHttp.WinHttpRequest class 
> (https://msdn.microsoft.com/en-us/library/windows/desktop/aa384106%28v=vs.85%29.aspx)
> The issue is that when I try and send a body of the request, I get the same 
> error as shown in this JIRA.
> Within cURL it's possible to workaround as described by Mark Frazier, but I 
> have tried a few approaches on this WITHIN VBA and failed to get it to work.
> What I propose to do is to create a github repository with the VBA code and 
> instructions on how to replicate, but I am not sure if that's how you guys 
> work? Do you actually work with implementations in languages, or is it just 
> the case that it it works with cURL then the other language implementation is 
> viewed as being at fault?
> Can you please give me some guidance on how I can work with you to get this 
> resolved?
> Replication code at: 
> https://github.com/JohnGreenan/ApacheActiveMQ.REST.winhttp



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