[jira] [Created] (AMQ-6001) AMQP: Refill sender credit faster to avoid throttling fast producers

2015-10-06 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQ-6001:
-

 Summary: AMQP: Refill sender credit faster to avoid throttling 
fast producers
 Key: AMQ-6001
 URL: https://issues.apache.org/jira/browse/AMQ-6001
 Project: ActiveMQ
  Issue Type: Improvement
  Components: AMQP
Affects Versions: 5.12.0
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Minor
 Fix For: 5.12.1, 5.13.0


We should send back credit a bit faster so that a remote sender that is fast 
doesn't have to pause waiting for more credit.



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

[jira] [Resolved] (AMQ-6001) AMQP: Refill sender credit faster to avoid throttling fast producers

2015-10-06 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-6001.
---
Resolution: Fixed

> AMQP: Refill sender credit faster to avoid throttling fast producers
> 
>
> Key: AMQ-6001
> URL: https://issues.apache.org/jira/browse/AMQ-6001
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 5.12.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.12.1, 5.13.0
>
>
> We should send back credit a bit faster so that a remote sender that is fast 
> doesn't have to pause waiting for more credit.



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

[jira] [Created] (AMQ-6000) Pause/resume feature of ActiveMQ not resuming properly

2015-10-06 Thread M Rahimi (JIRA) 
M Rahimi created AMQ-6000:
-

 Summary: Pause/resume feature of ActiveMQ not resuming properly
 Key: AMQ-6000
 URL: https://issues.apache.org/jira/browse/AMQ-6000
 Project: ActiveMQ
  Issue Type: Sub-task
  Components: Broker, JMX
Affects Versions: 5.12.0
Reporter: M Rahimi
 Fix For: 5.12.0


The problem is that, when you *resume* the message delivery,

# If there is a message entering the queue: the broker will immediately send 
the pending messages to the consumer which is totally OK.
# But if no message _enters_ the queue: the pending messages in the queue will 
not be sent to the consumers until the expiration checking is performed on the 
queue (which by default is 30 seconds and can be controlled by the 
_expireMessagesPeriod_ attribute) and non-expired messages will be sent to the 
consumers afterwards.

Obviously we can change the _expireMessagesPeriod_ to limit this delay, but 
when you need a milisec precision, performing the expiration check every 
milisec will not make sense.
How is it possible to force the queue to start sending messages immediately 
after resumption?



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

[jira] [Updated] (AMQ-6000) Pause/resume feature of ActiveMQ not resuming properly

2015-10-06 Thread M Rahimi (JIRA) 

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

M Rahimi updated AMQ-6000:
--
Labels: features  (was: )

> Pause/resume feature of ActiveMQ not resuming properly
> --
>
> Key: AMQ-6000
> URL: https://issues.apache.org/jira/browse/AMQ-6000
> Project: ActiveMQ
>  Issue Type: Sub-task
>  Components: Broker, JMX
>Affects Versions: 5.12.0
>Reporter: M Rahimi
>  Labels: features
> Fix For: 5.12.0
>
>
> The problem is that, when you *resume* the message delivery,
> # If there is a message entering the queue: the broker will immediately send 
> the pending messages to the consumer which is totally OK.
> # But if no message _enters_ the queue: the pending messages in the queue 
> will not be sent to the consumers until the expiration checking is performed 
> on the queue (which by default is 30 seconds and can be controlled by the 
> _expireMessagesPeriod_ attribute) and non-expired messages will be sent to 
> the consumers afterwards.
> Obviously we can change the _expireMessagesPeriod_ to limit this delay, but 
> when you need a milisec precision, performing the expiration check every 
> milisec will not make sense.
> How is it possible to force the queue to start sending messages immediately 
> after resumption?



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

[jira] [Updated] (AMQ-6000) Pause/resume feature of ActiveMQ not resuming properly

2015-10-06 Thread M Rahimi (JIRA) 

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

M Rahimi updated AMQ-6000:
--
Fix Version/s: (was: 5.12.0)

> Pause/resume feature of ActiveMQ not resuming properly
> --
>
> Key: AMQ-6000
> URL: https://issues.apache.org/jira/browse/AMQ-6000
> Project: ActiveMQ
>  Issue Type: Sub-task
>  Components: Broker, JMX
>Affects Versions: 5.12.0
>Reporter: M Rahimi
>  Labels: features
>
> The problem is that, when you *resume* the message delivery,
> # If there is a message entering the queue: the broker will immediately send 
> the pending messages to the consumer which is totally OK.
> # But if no message _enters_ the queue: the pending messages in the queue 
> will not be sent to the consumers until the expiration checking is performed 
> on the queue (which by default is 30 seconds and can be controlled by the 
> _expireMessagesPeriod_ attribute) and non-expired messages will be sent to 
> the consumers afterwards.
> Obviously we can change the _expireMessagesPeriod_ to limit this delay, but 
> when you need a milisec precision, performing the expiration check every 
> milisec will not make sense.
> How is it possible to force the queue to start sending messages immediately 
> after resumption?



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

[jira] [Commented] (AMQ-6000) Pause/resume feature of ActiveMQ not resuming properly

2015-10-06 Thread Gary Tully (JIRA) 

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

Gary Tully commented on AMQ-6000:
-

To sort this, I think there should be a call to wakeup() in 
org.apache.activemq.broker.region.Queue#resumeDispatch

> Pause/resume feature of ActiveMQ not resuming properly
> --
>
> Key: AMQ-6000
> URL: https://issues.apache.org/jira/browse/AMQ-6000
> Project: ActiveMQ
>  Issue Type: Sub-task
>  Components: Broker, JMX
>Affects Versions: 5.12.0
>Reporter: M Rahimi
>  Labels: features
>
> The problem is that, when you *resume* the message delivery,
> # If there is a message entering the queue: the broker will immediately send 
> the pending messages to the consumer which is totally OK.
> # But if no message _enters_ the queue: the pending messages in the queue 
> will not be sent to the consumers until the expiration checking is performed 
> on the queue (which by default is 30 seconds and can be controlled by the 
> _expireMessagesPeriod_ attribute) and non-expired messages will be sent to 
> the consumers afterwards.
> Obviously we can change the _expireMessagesPeriod_ to limit this delay, but 
> when you need a milisec precision, performing the expiration check every 
> milisec will not make sense.
> How is it possible to force the queue to start sending messages immediately 
> after resumption?



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

[jira] [Created] (ARTEMIS-244) wrong property name used in ColocatedHAManager server-id

2015-10-06 Thread Andy Taylor (JIRA) 
Andy Taylor created ARTEMIS-244:
---

 Summary: wrong property name used in ColocatedHAManager server-id
 Key: ARTEMIS-244
 URL: https://issues.apache.org/jira/browse/ARTEMIS-244
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Andy Taylor
Assignee: Andy Taylor


This was changed and should now be serverId



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

[jira] [Resolved] (AMQ-5994) Broker can't recover Durable Subscription on index deletion

2015-10-06 Thread Gary Tully (JIRA) 

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

Gary Tully resolved AMQ-5994.
-
   Resolution: Fixed
Fix Version/s: 5.13.0

[~cshannon] thanks for the test!

> Broker can't recover Durable Subscription on index deletion
> ---
>
> Key: AMQ-5994
> URL: https://issues.apache.org/jira/browse/AMQ-5994
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.12.0
>Reporter: Christopher L. Shannon
>Assignee: Gary Tully
> Fix For: 5.13.0
>
> Attachments: SubscriptionRecoveryTest.java
>
>
> The broker is unable to recover a durable subscription when replaying the 
> journal to rebuild the index, if the original index was deleted.  The problem 
> is that when the index is recovered, any KahaSubscriptionCommand is ignored 
> so the messages are never recovered because when the messages are replayed 
> the subscriptions don't exist.
> I modified AMQ4212Test.java to demonstrate this issue and I have attached it.
> It looks like the fix for AMQ-4000 is what introduces this problem. 
> The commit for that issue is is : 
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=0061f6f75538ede8fe3443925e64beb839abfb90



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

[jira] [Commented] (AMQ-4000) Durable subscription not getting unregistered on networked broker

2015-10-06 Thread ASF subversion and git services (JIRA) 

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

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

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

https://issues.apache.org/jira/browse/AMQ-5994 
https://issues.apache.org/jira/browse/AMQ-4000 - proper fix for duplicate sub 
info from the store on recovery failure from AMQ2149Test. Additional test from 
Christopher L


> Durable subscription not getting unregistered on networked broker
> -
>
> Key: AMQ-4000
> URL: https://issues.apache.org/jira/browse/AMQ-4000
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0
> Environment: network of brokers, durable topic subscriptions.
>Reporter: Torsten Mielke
>Assignee: Christian Posta
>  Labels: durable_subscription, networks
> Fix For: 5.10.0
>
> Attachments: JUnitTest.patch
>
>
> In a network of two brokers, a durable subscription is correctly propagated 
> across to the remote broker. However when the consumer unsubscribes from the 
> durable subscription again, it is only removed on the local broker but not on 
> the remote broker. The remote broker keeps its durable subscription alive.
> As a consequence messages sent to the topic destination on the remote broker 
> for which the durable subscriptions existed, are passed on to the local 
> broker, although there is no active subscription on the local broker. The 
> local broker will discard these msgs but unnecessary traffic has already 
> occurred on the network bridge.



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

[jira] [Commented] (AMQ-5994) Broker can't recover Durable Subscription on index deletion

2015-10-06 Thread ASF subversion and git services (JIRA) 

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

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

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

https://issues.apache.org/jira/browse/AMQ-5994 
https://issues.apache.org/jira/browse/AMQ-4000 - proper fix for duplicate sub 
info from the store on recovery failure from AMQ2149Test. Additional test from 
Christopher L


> Broker can't recover Durable Subscription on index deletion
> ---
>
> Key: AMQ-5994
> URL: https://issues.apache.org/jira/browse/AMQ-5994
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, KahaDB
>Affects Versions: 5.12.0
>Reporter: Christopher L. Shannon
>Assignee: Gary Tully
> Fix For: 5.13.0
>
> Attachments: SubscriptionRecoveryTest.java
>
>
> The broker is unable to recover a durable subscription when replaying the 
> journal to rebuild the index, if the original index was deleted.  The problem 
> is that when the index is recovered, any KahaSubscriptionCommand is ignored 
> so the messages are never recovered because when the messages are replayed 
> the subscriptions don't exist.
> I modified AMQ4212Test.java to demonstrate this issue and I have attached it.
> It looks like the fix for AMQ-4000 is what introduces this problem. 
> The commit for that issue is is : 
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=0061f6f75538ede8fe3443925e64beb839abfb90



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

[jira] [Commented] (AMQ-593) Slave does not detect master failover when master is solaris and slave on windows

2015-10-06 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on AMQ-593:


GitHub user czobrisky opened a pull request:

https://github.com/apache/activemq/pull/149

AMQ-593 - Updated jodatime to 2.8.2

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

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

$ git pull https://github.com/czobrisky/activemq AMQ-5931

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

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


commit 10c68966567759dd25904c52c40c379c8d188019
Author: Chad Zobrisky 
Date:   2015-10-06T15:54:44Z

Updated jodatime to 2.8.2




> Slave does not detect master failover when master is solaris and slave on 
> windows
> -
>
> Key: AMQ-593
> URL: https://issues.apache.org/jira/browse/AMQ-593
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.0 M4
> Environment: solaris/windows
>Reporter: Rob Davies
>Assignee: Adrian Co
>Priority: Critical
> Attachments: ASF.LICENSE.NOT.GRANTED--activemq.xml, 
> ASF.LICENSE.NOT.GRANTED--masterlog.txt, 
> ASF.LICENSE.NOT.GRANTED--myconfig.xml, ASF.LICENSE.NOT.GRANTED--slavelog.txt, 
> ASF.LICENSE.NOT.GRANTED--stacktrace.txt
>
>
> clients on windows don't failover to slave - see 
> http://forums.activemq.org/posts/list/409.page



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

[jira] [Updated] (AMQ-5931) Update joda-time version used in activemq karaf features

2015-10-06 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon updated AMQ-5931:

Issue Type: Sub-task  (was: Task)
Parent: AMQ-5957

> Update joda-time version used in activemq karaf features
> 
>
> Key: AMQ-5931
> URL: https://issues.apache.org/jira/browse/AMQ-5931
> Project: ActiveMQ
>  Issue Type: Sub-task
>  Components: karaf
>Affects Versions: 5.11.2
>Reporter: Grzegorz Grzybek
>
> joda-time is used [in activemq karaf 
> feature|https://github.com/apache/activemq/blob/activemq-5.11.2/activemq-karaf/src/main/resources/features-core.xml#L54]
>  but it's needed only by XStream library.
> The [XStream version 
> used|https://github.com/apache/activemq/blob/activemq-5.11.2/activemq-karaf/pom.xml#L38]
>  has the following osgi import range:
> {noformat}
> Import-Package = 
> ...
>   org.joda.time;resolution:=optional;version="[1.6,3)",
>   org.joda.time.format;resolution:=optional;version="[1.6,3)",
> ...
> {noformat}
> So joda-time may be upated to newer version.



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

[jira] [Created] (ARTEMIS-245) Change resource adapter to work with Tomee

2015-10-06 Thread clebert suconic (JIRA) 
clebert suconic created ARTEMIS-245:
---

 Summary: Change resource adapter to work with Tomee
 Key: ARTEMIS-245
 URL: https://issues.apache.org/jira/browse/ARTEMIS-245
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: clebert suconic
 Fix For: 1.1.1


It seems that Tomee requires a JMS interface to be returned. We should try 
changing the RA to be compatible with it.



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

[jira] [Commented] (AMQ-6001) AMQP: Refill sender credit faster to avoid throttling fast producers

2015-10-06 Thread ASF subversion and git services (JIRA) 

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

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

Commit 789419ab9d87b735688adb5843427fb4deaea590 in activemq's branch 
refs/heads/activemq-5.12.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=789419a ]

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

Refill credit at a slightly faster rate.
(cherry picked from commit bbcd93803207f22d6c549bc79dd7d0c28e16be26)


> AMQP: Refill sender credit faster to avoid throttling fast producers
> 
>
> Key: AMQ-6001
> URL: https://issues.apache.org/jira/browse/AMQ-6001
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 5.12.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.12.1, 5.13.0
>
>
> We should send back credit a bit faster so that a remote sender that is fast 
> doesn't have to pause waiting for more credit.



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