[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225383942
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
 ---
@@ -1789,6 +1790,11 @@ public synchronized RoutingStatus doSend(final 
Transaction tx,
 
   AddressInfo art = getAddressAndRoutingType(new 
AddressInfo(msg.getAddressSimpleString(), routingType));
 
+  if (postOffice.isAddressBlocked(msg.getAddressSimpleString())) {
--- End diff --

You mean a formal discussion? I'll send an email for that purpose. I think 
it not too late. :)


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré commented on AMQ-7067:
---

Thanks for the update guys. I'm fixing AMQ-7076 and AMQ-7073 on my side.

Please let me know when I can start 5.15.7 release. Thanks !

> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different data files.
> 
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Assignee: Gary Tully
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different data files.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with 
> 512 * 1024 characters in message payload). This forces a new data file to be 
> created.
> Commit the XA transaction. Commit will land on the new data file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is 
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress 
> tx{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] 
> != {color:#cc7832}null{color}) {
>  {color:#cc7832}for {color}({color:#cc7832}int 
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
>  {color}pendingTx <= 
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832}; 
> {color}pendingTx++) {
>  gcCandidateSet.remove(pendingTx){color:#cc7832};{color} }
>  }
> We need to become aware of where the prepare & commits occur in pagefiles 
> with respect to GCing files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225357936
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
 ---
@@ -1789,6 +1790,11 @@ public synchronized RoutingStatus doSend(final 
Transaction tx,
 
   AddressInfo art = getAddressAndRoutingType(new 
AddressInfo(msg.getAddressSimpleString(), routingType));
 
+  if (postOffice.isAddressBlocked(msg.getAddressSimpleString())) {
--- End diff --

We should have discussed this before you coming into implementation. 

I don't think this is the right design.


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225353248
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
 ---
@@ -1789,6 +1790,11 @@ public synchronized RoutingStatus doSend(final 
Transaction tx,
 
   AddressInfo art = getAddressAndRoutingType(new 
AddressInfo(msg.getAddressSimpleString(), routingType));
 
+  if (postOffice.isAddressBlocked(msg.getAddressSimpleString())) {
--- End diff --

btw my test missed stomp and mqtt, I'll add them.


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225353155
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
 ---
@@ -1789,6 +1790,11 @@ public synchronized RoutingStatus doSend(final 
Transaction tx,
 
   AddressInfo art = getAddressAndRoutingType(new 
AddressInfo(msg.getAddressSimpleString(), routingType));
 
+  if (postOffice.isAddressBlocked(msg.getAddressSimpleString())) {
--- End diff --

@clebertsuconic reply here.
I can think of 2 difficulties using credits:
1. Some clients (like mqtt, stomp) are not supporting flow control so they 
can't be blocked using credits.
2. producers are not necessarily bound to one address, they can send 
messages to different addresses (for example one producer can send one message 
to address1, and the next one to address2. It it's blocked on address1, the 
next message also be blocked)

If we simply block the sending threads, it will holding up broker threads 
(like you said OME). Besides the producer may have call-timeout exception.

By throwing a proper exception we can let client to handle their producer 
properly without blocking any thing.



> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (ARTEMIS-2111) ManagementContext can leak

2018-10-15 Thread Justin Bertram (JIRA)


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

Justin Bertram resolved ARTEMIS-2111.
-
   Resolution: Fixed
Fix Version/s: 2.6.4
   2.7.0

> ManagementContext can leak
> --
>
> Key: ARTEMIS-2111
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2111
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0, 2.6.4
>
>
> If a {{management-context}} {{connector}} is configured in {{management.xml}} 
> (e.g. below) and 
> {{org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl#stop(boolean,
>  boolean, boolean)}} is called (e.g. due to criticalIOErrors) the JVM will 
> not exit due to a handful of leaked RMI related threads for the MBean server 
> implementation.
> {code:xml}
> http://activemq.org/schema;>
>
>...
> 
> {code}
> Here's an example thread dump after the broker has stopped:
> {noformat}
> 2018-08-10 10:47:59
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode):
> "Attach Listener" #122 daemon prio=9 os_prio=31 tid=0x7fe609a37800 
> nid=0x920f waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "DestroyJavaVM" #57 prio=5 os_prio=31 tid=0x7fe60a000800 nid=0x1c03 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "RMI RenewClean-[192.168.1.125:62416]" #20 daemon prio=5 os_prio=31 
> tid=0x7fe609432800 nid=0x7f03 in Object.wait() [0x7672e000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at 
> sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:536)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI Scheduler(0)" #19 daemon prio=5 os_prio=31 tid=0x7fe60c2c4000 
> nid=0x7d03 waiting on condition [0x7662b000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x00074017e5b8> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "GC Daemon" #17 daemon prio=2 os_prio=31 tid=0x7fe60c2bb000 nid=0x7903 in 
> Object.wait() [0x76425000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>   at sun.misc.GC$Daemon.run(GC.java:117)
>   - locked <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>Locked ownable synchronizers:
>   - None
> "RMI Reaper" #16 prio=5 os_prio=31 tid=0x7fe60d001800 nid=0x7703 in 
> Object.wait() [0x76322000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
>   at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI TCP Accept-0" #15 daemon prio=5 os_prio=31 tid=0x7fe60a902000 
> nid=0x7503 runnable [0x7621f000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.PlainSocketImpl.socketAccept(Native Method)
>   at 
> 

[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Daniel Kulp (JIRA)


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

Daniel Kulp commented on AMQ-7072:
--

For the record, I'm OK with moving to JSON-B (for 5.16, not 5.15), but I'm also 
against moving from Jackson to Johnson. 


> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7070) Priority is not being respected when the cursor cache flips

2018-10-15 Thread Alan Protasio (JIRA)


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

Alan Protasio commented on AMQ-7070:


Hi [~gtully]

I ran the test with this change:

https://github.com/alanprot/activemq/commit/3dc691335f6ae749c2d40602d6b33cb02f7eb0b3

Seems the only test that failed were:
{quote}{{StoreQueueCursorOrderTest.testNoSetBatchWithUnOrderedFutureCurrentSync:204
 expected:<0> but was:<1>}}
{{ StoreQueueCursorOrderTest.tesBlockedFuture:136 expected:<0> but was:<1>}}
{{ StoreQueueCursorOrderTest.testSetBatchWithFuture:362 setBatch set 
expected:<2> but was:<0>}}
{{ StoreQueueCursorOrderTest.testSetBatchWithOrderedFutureCurrentFuture:269 
setBatch set expected:<1> but was:<0>}}
{{ StoreQueueCursorOrderTest.testSetBatch:435 setBatch set expected:<2> but 
was:<0>}}
{{ TopicProducerDurableSubFlowControlTest.testTopicProducerFlowControl:184 Has 
a decent usage}}
{quote}
 

The first ones (StoreQueueCursorOrderTest) failed because the Storage and the 
cache has different orders. As I'm purging the cache.. the order of messages 
dispatched changed (now they are being dispatched in the same order as they 
were store - with I think is the right behaviour as the store should be the 
source of truth).

The TopicProducerDurableSubFlowControlTest failed because one of the asserts 
was to check if the cursor was using more then 5% of  memory but as I purged 
the cache, this was not the case.

 

But, to be honest here.. i donno if this change worth... as this change is not 
solving 100% of the cases. Even if i purge the cache when disabling the cache, 
i can still receive messages with wrong priority in the case where i'm sending 
messages with higher priority and the cursor was filled with messages with 
lower priority from the disk. At least in this case the cursor is filled in 
batch of 200 messages instead of the case when we are disabling the cache and 
this cursor can be filled with GBs of messages. 

Thanks

 

> Priority is not being respected when the cursor cache flips
> ---
>
> Key: AMQ-7070
> URL: https://issues.apache.org/jira/browse/AMQ-7070
> Project: ActiveMQ
>  Issue Type: Test
>  Components: Broker
>Reporter: Alan Protasio
>Priority: Minor
> Attachments: AMQ7070Test.java
>
>
> Messages are being dispatched with wrong priority when the cache is flipped.
> See: 
> https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258
> All messages that could get cached in the cursor are dispatched before even 
> though massages with higher priority is in the cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2126) Web server can leak

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2126:
-

GitHub user jbertram opened a pull request:

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

ARTEMIS-2126 web server can leak



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

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

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

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


commit 255d616b95f53badb30be83316c18f365e6acb99
Author: Justin Bertram 
Date:   2018-10-15T16:06:24Z

ARTEMIS-2126 web server can leak




> Web server can leak
> ---
>
> Key: ARTEMIS-2126
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2126
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> If the broker shuts itself down due to a critical IO error (e.g. can't access 
> persistent storage) the embedded web server will not be shutdown and will 
> leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-2126) Web server can leak

2018-10-15 Thread Justin Bertram (JIRA)
Justin Bertram created ARTEMIS-2126:
---

 Summary: Web server can leak
 Key: ARTEMIS-2126
 URL: https://issues.apache.org/jira/browse/ARTEMIS-2126
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Justin Bertram
Assignee: Justin Bertram


If the broker shuts itself down due to a critical IO error (e.g. can't access 
persistent storage) the embedded web server will not be shutdown and will leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Romain Manni-Bucau (JIRA)


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

Romain Manni-Bucau commented on AMQ-7072:
-

[~cshannon] the point is not about aligning the impl on tomee but more about 
using apache impl instead of jackson which was pretty alone when imported in 
AMQ. This is why it is johnzon and not yasson typically. On the "users might 
then be using Jackson for other Json serialization that is pulled in by 
ActiveMQ through maven" which is a correct point you can also notice that this 
is not intended and not an API exposed by API but it is *leaked* by AMQ so all 
good to not pull it anymore. If a user relies on jackson in its app he should 
have added it directly in its pom and not rely on transitive deps which is a 
very bad practise - several validation maven plugins fail the build on such 
practises.

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7076) Features repository should refer the spring-legacy one

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on AMQ-7076:
-

GitHub user jbonofre opened a pull request:

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

[AMQ-7076] Fix and update features to fully support Karaf 4.2.x



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

$ git pull https://github.com/jbonofre/activemq AMQ-7076

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

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


commit 87a7da20920c8608bf7207910251d6cc8b21cd76
Author: Jean-Baptiste Onofré 
Date:   2018-10-15T15:37:38Z

[AMQ-7076] Fix and update features to fully support Karaf 4.2.x




> Features repository should refer the spring-legacy one
> --
>
> Key: AMQ-7076
> URL: https://issues.apache.org/jira/browse/AMQ-7076
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: OSGi/Karaf
>Affects Versions: 5.15.6
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0, 5.15.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (AMQ-5245) activemq:bstat doesn't work in Karaf

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré resolved AMQ-5245.
---
Resolution: Fixed

> activemq:bstat doesn't work in Karaf
> 
>
> Key: AMQ-5245
> URL: https://issues.apache.org/jira/browse/AMQ-5245
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: OSGi/Karaf
>Affects Versions: 5.9.1
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> {code}
> karaf@root()> activemq:bstat 
> ERROR: java.lang.RuntimeException: Failed to execute query task. Reason: 
> java.lang.IllegalStateException: Attribute Uptime can not be found
> java.lang.RuntimeException: Failed to execute query task. Reason: 
> java.lang.IllegalStateException: Attribute Uptime can not be found
> at 
> org.apache.activemq.console.command.QueryCommand.runTask(QueryCommand.java:131)
> at 
> org.apache.activemq.console.command.BstatCommand.runTask(BstatCommand.java:86)
> at 
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at 
> org.apache.activemq.console.command.AbstractJmxCommand.execute(AbstractJmxCommand.java:387)
> at 
> org.apache.activemq.karaf.commands.ActiveMQCommandSupport.doExecute(ActiveMQCommandSupport.java:46)
> at 
> org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)
> at 
> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:39)
> at 
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)
> at Proxy71c61764_cfe8_42c8_9401_198eac480ee5.execute(Unknown Source)
> at Proxy71c61764_cfe8_42c8_9401_198eac480ee5.execute(Unknown Source)
> at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
> at 
> org.apache.karaf.shell.console.impl.jline.ConsoleImpl$DelegateSession.execute(ConsoleImpl.java:521)
> at 
> org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.java:212)
> at java.lang.Thread.run(Thread.java:744)
> at 
> org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.doRun(ConsoleFactoryService.java:126)
> at 
> org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3$1.run(ConsoleFactoryService.java:117)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.java:47)
> at 
> org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.run(ConsoleFactoryService.java:115)
> Error executing command: java.lang.IllegalStateException: Attribute Uptime 
> can not be found
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (AMQ-7014) Separate Karaf integration from main ActiveMQ feature

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré reassigned AMQ-7014:
-

Assignee: Jean-Baptiste Onofré

> Separate Karaf integration from main ActiveMQ feature
> -
>
> Key: AMQ-7014
> URL: https://issues.apache.org/jira/browse/AMQ-7014
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: karaf, OSGi/Karaf
>Affects Versions: 5.15.4
>Reporter: Łukasz Dywicki
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 5.16.0
>
>
> Currently activemq feature installs also karaf console integration. In some 
> cases it might be useful to separate these two so console integration is 
> optional and not crucial in all cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7014) Separate Karaf integration from main ActiveMQ feature

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7014:
--
Fix Version/s: (was: 5.15.7)

> Separate Karaf integration from main ActiveMQ feature
> -
>
> Key: AMQ-7014
> URL: https://issues.apache.org/jira/browse/AMQ-7014
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: karaf, OSGi/Karaf
>Affects Versions: 5.15.4
>Reporter: Łukasz Dywicki
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 5.16.0
>
>
> Currently activemq feature installs also karaf console integration. In some 
> cases it might be useful to separate these two so console integration is 
> optional and not crucial in all cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7014) Separate Karaf integration from main ActiveMQ feature

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7014:
--
Fix Version/s: 5.15.7
   5.16.0

> Separate Karaf integration from main ActiveMQ feature
> -
>
> Key: AMQ-7014
> URL: https://issues.apache.org/jira/browse/AMQ-7014
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: karaf, OSGi/Karaf
>Affects Versions: 5.15.4
>Reporter: Łukasz Dywicki
>Priority: Minor
> Fix For: 5.16.0
>
>
> Currently activemq feature installs also karaf console integration. In some 
> cases it might be useful to separate these two so console integration is 
> optional and not crucial in all cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (AMQ-5749) activemq-karaf bundle can't be installed into Karaf container

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré resolved AMQ-5749.
---
Resolution: Not A Problem

> activemq-karaf bundle can't be installed into Karaf container
> -
>
> Key: AMQ-5749
> URL: https://issues.apache.org/jira/browse/AMQ-5749
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: OSGi/Karaf
>Affects Versions: 5.11.1
>Reporter: Xilai Dai
>Priority: Major
>
> {code}
> karaf@root()> feature:install activemq
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=activ
> karaf.feature; version="[5.11.1,5.11.1]"; 
> filter:="(&(osgi.identity=activemq)(type=karaf.feature)(version>=5.1
> on<=5.11.1))" [caused by: Unable to resolve activemq/5.11.1: missing 
> requirement [activemq/5.11.1] osgi.identi
> dentity=activemq-karaf; type=osgi.bundle; version="[5.11.1,5.11.1]"; 
> resolution:=mandatory [caused by: Unable
>  activemq-karaf/5.11.1: missing requirement [activemq-karaf/5.11.1] 
> osgi.wiring.package; filter:="(&(osgi.wiri
> =org.apache.felix.service.command)(version>=0.12.0)(!(version>=1.0.0)))"]]
> {code}
> In the previous version 5.10.0, the Import-Package: of this bundle has:
> {code}
> ..
> org.apache.felix.service.command;status=provisional;
> ..
> {code}
> but in the current 5.11.1 version, the Import-Package: looks like:
> {code}
> ..
> org.apache.felix.service.command;version="[0.12,1)"
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-7072:
-

I don't get the rational for changing the default Json serializer.  Changing 
the Json implementation just because another product(TomEE) uses a different 
implementation is not a good reason.  I see no valid reason to not stick with 
Jackson which works very well and is very fast. 

One issue is there are transitive dependencies on Jackson if someone runs an 
embedded broker.  So people that are current users might then be using Jackson 
for other Json serialization that is pulled in by ActiveMQ through maven.  
Making this change would require those existing users to have to now add a 
dependency on Jackson for themselves. While this is possible of course I don't 
see why we should make all the existing users that might be relying on Jackson 
have to go change their configuration just because TomEE doesn't allow jackson 
without a good reason to do so.


> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Romain Manni-Bucau (JIRA)


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

Romain Manni-Bucau commented on AMQ-7072:
-

Hmm, I don't get the rational here, if you review the adherence it is only 
about "ignore unknown properties" and "rename this field as xxx" so the switch 
is safe. Do you expect any internals dependency?

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (AMQ-7076) Features repository should refer the spring-legacy one

2018-10-15 Thread JIRA
Jean-Baptiste Onofré created AMQ-7076:
-

 Summary: Features repository should refer the spring-legacy one
 Key: AMQ-7076
 URL: https://issues.apache.org/jira/browse/AMQ-7076
 Project: ActiveMQ
  Issue Type: Bug
  Components: OSGi/Karaf
Affects Versions: 5.15.6
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
 Fix For: 5.16.0, 5.15.7






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Timothy Bish (JIRA)


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

Timothy Bish commented on AMQ-7072:
---

Agree with [~cshannon] on this, the default ought to remain as it is now 
Jackson. We could make the provider implementation swappable on master for a 
future 5.16.0 release, that makes sense.  

We shouldn't be changing out things like this on the patch branch though. 

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7073) MQTT tests are failing

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-7073:
-

This test has been failing for a very long time intermittently

> MQTT tests are failing
> --
>
> Key: AMQ-7073
> URL: https://issues.apache.org/jira/browse/AMQ-7073
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.7
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.15.7
>
>
> The {{activemq-mqtt}} tests are failing on master right now. I'm 
> investigating and I will fix that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-7072:
-

i didn't say we couldn't use JSON-B, that part is fine if we want to move 
towards that API for the next major release.

My objection is to replacing the default implementation and dropping Jackson 
which has been used for many years, plus it is probably one of the most popular 
libraries out there (if not the most popular). If we use JSON-B then you can 
simply replace the implementation for your use case and not make everyone else 
have to change their setup as the vast majority of users are probably just 
happy with Jackson considering there have been no complaints until now.

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7073) MQTT tests are failing

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré commented on AMQ-7073:
---

It works fine on {{master}} but fails on {{activemq-5.15.x}}:

{code}
MQTTNIOSSLTest>MQTTTest.testReceiveMessageSentWhileOffline:1698 Should have 
received 202 messages expected:<202> but was:<14>
{code}

> MQTT tests are failing
> --
>
> Key: AMQ-7073
> URL: https://issues.apache.org/jira/browse/AMQ-7073
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.7
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.15.7
>
>
> The {{activemq-mqtt}} tests are failing on master right now. I'm 
> investigating and I will fix that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (AMQ-7073) MQTT tests are failing

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré reopened AMQ-7073:
---

> MQTT tests are failing
> --
>
> Key: AMQ-7073
> URL: https://issues.apache.org/jira/browse/AMQ-7073
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.7
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.15.7
>
>
> The {{activemq-mqtt}} tests are failing on master right now. I'm 
> investigating and I will fix that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7073) MQTT tests are failing

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7073:
--
Fix Version/s: 5.15.7

> MQTT tests are failing
> --
>
> Key: AMQ-7073
> URL: https://issues.apache.org/jira/browse/AMQ-7073
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.7
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.15.7
>
>
> The {{activemq-mqtt}} tests are failing on master right now. I'm 
> investigating and I will fix that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7073) MQTT tests are failing

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7073:
--
Affects Version/s: 5.15.7

> MQTT tests are failing
> --
>
> Key: AMQ-7073
> URL: https://issues.apache.org/jira/browse/AMQ-7073
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.7
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.15.7
>
>
> The {{activemq-mqtt}} tests are failing on master right now. I'm 
> investigating and I will fix that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Romain Manni-Bucau (JIRA)


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

Romain Manni-Bucau commented on AMQ-7072:
-

[~cshannon] well JSON-B was not there years ago or java 8 base was not in AMQ 
project, now it is the case AMQ should pay its debt and move forward, this is 
what this ticket is about

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2111) ManagementContext can leak

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2111:
-

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2347
  
@michalxo, in your test is it the management context that's leaking or 
something else?


> ManagementContext can leak
> --
>
> Key: ARTEMIS-2111
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2111
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> If a {{management-context}} {{connector}} is configured in {{management.xml}} 
> (e.g. below) and 
> {{org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl#stop(boolean,
>  boolean, boolean)}} is called (e.g. due to criticalIOErrors) the JVM will 
> not exit due to a handful of leaked RMI related threads for the MBean server 
> implementation.
> {code:xml}
> http://activemq.org/schema;>
>
>...
> 
> {code}
> Here's an example thread dump after the broker has stopped:
> {noformat}
> 2018-08-10 10:47:59
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode):
> "Attach Listener" #122 daemon prio=9 os_prio=31 tid=0x7fe609a37800 
> nid=0x920f waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "DestroyJavaVM" #57 prio=5 os_prio=31 tid=0x7fe60a000800 nid=0x1c03 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "RMI RenewClean-[192.168.1.125:62416]" #20 daemon prio=5 os_prio=31 
> tid=0x7fe609432800 nid=0x7f03 in Object.wait() [0x7672e000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at 
> sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:536)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI Scheduler(0)" #19 daemon prio=5 os_prio=31 tid=0x7fe60c2c4000 
> nid=0x7d03 waiting on condition [0x7662b000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x00074017e5b8> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "GC Daemon" #17 daemon prio=2 os_prio=31 tid=0x7fe60c2bb000 nid=0x7903 in 
> Object.wait() [0x76425000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>   at sun.misc.GC$Daemon.run(GC.java:117)
>   - locked <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>Locked ownable synchronizers:
>   - None
> "RMI Reaper" #16 prio=5 os_prio=31 tid=0x7fe60d001800 nid=0x7703 in 
> Object.wait() [0x76322000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
>   at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI TCP Accept-0" #15 daemon prio=5 os_prio=31 tid=0x7fe60a902000 
> nid=0x7503 runnable [0x7621f000]

[jira] [Updated] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Timothy Bish (JIRA)


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

Timothy Bish updated AMQ-7072:
--
Fix Version/s: (was: 5.15.7)

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7072:
--
Fix Version/s: 5.15.7

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0, 5.15.7
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7075) Camel tests failure

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré updated AMQ-7075:
--
Fix Version/s: 5.16.0

> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225165274
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
 ---
@@ -1789,6 +1790,11 @@ public synchronized RoutingStatus doSend(final 
Transaction tx,
 
   AddressInfo art = getAddressAndRoutingType(new 
AddressInfo(msg.getAddressSimpleString(), routingType));
 
+  if (postOffice.isAddressBlocked(msg.getAddressSimpleString())) {
--- End diff --

I think the use case here is wrong. With block you just stop sending 
credits to the client.

This becomes fail at this point.

We have two options:


- If you had previously sent credits to the client.. then you must complete 
the operations until you have full credits.

- or we could hung to these on the server. But that would have a risk of 
running OME. So I would say we just stop sending credits.


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (AMQ-7075) Camel tests failure

2018-10-15 Thread JIRA


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

Jean-Baptiste Onofré resolved AMQ-7075.
---
Resolution: Fixed

> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225164140
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQAddressBlockedException.java
 ---
@@ -0,0 +1,24 @@
+/*
+ * 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.api.core;
+
+public class ActiveMQAddressBlockedException extends ActiveMQException {
+
+   public ActiveMQAddressBlockedException(String address) {
--- End diff --

Why do you need a BlockedException? With block you just bock, no exceptions!


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7075) Camel tests failure

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on AMQ-7075:
-

Github user asfgit closed the pull request at:

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


> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7075) Camel tests failure

2018-10-15 Thread ASF subversion and git services (JIRA)


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

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

Commit e22703edc6974f705d29f1f88ff5fd879e3a9fe9 in activemq's branch 
refs/heads/master from [~j...@nanthrax.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e22703e ]

[AMQ-7075] Fix Camel test (userName instead of username)


> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7075) Camel tests failure

2018-10-15 Thread ASF subversion and git services (JIRA)


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

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

Commit 085dd4e6e1ca62f355547094e212bda13d8d0f57 in activemq's branch 
refs/heads/master from [~j...@nanthrax.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=085dd4e ]

[AMQ-7075] This closes #309


> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-7072:
-

I don't see any reason we need to change the default from Jackson.  There is no 
reason we can't use an external vendor. If the entire purpose is to make this 
portable and use JSON-B then we should keep Jackson as the default and allow 
someone to switch it out if they want.  Jackson has been used for many years 
and is one of the most popular JSON serializers (most people use it as the 
default) so I'm not in favor of changing the default at all.

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2124) Addresses/Queues are not auto-deleted in clusters

2018-10-15 Thread Johan Stenberg (JIRA)


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

Johan Stenberg commented on ARTEMIS-2124:
-

[~jbertram] shouldn't the queue be at least deleted on broker B once the last 
consumer disconnects from it? This also is not the case.

> Addresses/Queues are not auto-deleted in clusters
> -
>
> Key: ARTEMIS-2124
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2124
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.6.3
>Reporter: Johan Stenberg
>Priority: Major
> Attachments: Artemis2124_AutoDeleteTest.java
>
>
> All addresses and queues in one of our production cluster environment are 
> configured as auto create/delete addresses and queues, however non of the 
> addresses and queues are never seem to get auto-deleted.
> I am attaching a test case that I believe reproduces the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Romain Manni-Bucau (JIRA)


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

Romain Manni-Bucau commented on AMQ-7072:
-

[~cshannon] it is not only a single use case actually but N > 1 since you can 
have it as a user too. High level the goal is to reduce the implementation 
surfacing ActiveMQ and just relies on portable API. 
https://mvnrepository.com/artifact/io.devcon5/jackson-jsonb-provider/1.1 is 
usable for jackson. In terms of default impl, aligning our stack on an apache 
one is likely saner than relying on external vendors (for our own ecosystem) - 
"eat your own dogfood" ;).

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225143852
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQAddressBlockedException.java
 ---
@@ -0,0 +1,24 @@
+/*
+ * 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.api.core;
+
+public class ActiveMQAddressBlockedException extends ActiveMQException {
+
+   public ActiveMQAddressBlockedException(String address) {
--- End diff --

Yes that makes sense. We don't need the stacktrace here. I'll add that. thx.


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2111) ManagementContext can leak

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2111:
-

Github user michalxo commented on the issue:

https://github.com/apache/activemq-artemis/pull/2347
  
I have managed to reproduced this issue on VM by simply adding extra hdd, 
formatting it, and making Artemis to use it for bindings, journal, (etc..). 
Started broker, waited for all components to go up and simply deleted hdd from 
virt-manager. 


> ManagementContext can leak
> --
>
> Key: ARTEMIS-2111
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2111
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> If a {{management-context}} {{connector}} is configured in {{management.xml}} 
> (e.g. below) and 
> {{org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl#stop(boolean,
>  boolean, boolean)}} is called (e.g. due to criticalIOErrors) the JVM will 
> not exit due to a handful of leaked RMI related threads for the MBean server 
> implementation.
> {code:xml}
> http://activemq.org/schema;>
>
>...
> 
> {code}
> Here's an example thread dump after the broker has stopped:
> {noformat}
> 2018-08-10 10:47:59
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode):
> "Attach Listener" #122 daemon prio=9 os_prio=31 tid=0x7fe609a37800 
> nid=0x920f waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "DestroyJavaVM" #57 prio=5 os_prio=31 tid=0x7fe60a000800 nid=0x1c03 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "RMI RenewClean-[192.168.1.125:62416]" #20 daemon prio=5 os_prio=31 
> tid=0x7fe609432800 nid=0x7f03 in Object.wait() [0x7672e000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at 
> sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:536)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI Scheduler(0)" #19 daemon prio=5 os_prio=31 tid=0x7fe60c2c4000 
> nid=0x7d03 waiting on condition [0x7662b000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x00074017e5b8> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "GC Daemon" #17 daemon prio=2 os_prio=31 tid=0x7fe60c2bb000 nid=0x7903 in 
> Object.wait() [0x76425000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>   at sun.misc.GC$Daemon.run(GC.java:117)
>   - locked <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>Locked ownable synchronizers:
>   - None
> "RMI Reaper" #16 prio=5 os_prio=31 tid=0x7fe60d001800 nid=0x7703 in 
> Object.wait() [0x76322000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
>   at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
>   at java.lang.Thread.run(Thread.java:745)
>

[jira] [Commented] (ARTEMIS-2111) ManagementContext can leak

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2111:
-

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

https://github.com/apache/activemq-artemis/pull/2347#discussion_r225120812
  
--- Diff: 
artemis-cli/src/test/java/org/apache/activemq/cli/test/ArtemisTest.java ---
@@ -233,6 +237,21 @@ public void testWebConfig() throws Exception {
   assertEquals("password2", trustPass);
}
 
+   @Test
+   public void testStopManagementContext() throws Exception {
+  Run.setEmbedded(true);
+  File instance1 = new File(temporaryFolder.getRoot(), 
"instance_user");
+  System.setProperty("java.security.auth.login.config", 
instance1.getAbsolutePath() + "/etc/login.config");
+  Artemis.main("create", instance1.getAbsolutePath(), "--silent", 
"--no-autotune", "--no-web", "--no-amqp-acceptor", "--no-mqtt-acceptor", 
"--no-stomp-acceptor", "--no-hornetq-acceptor");
--- End diff --

Can we enhance this test (better to copy this one) and use by default web 
console as well?
Else Artemis process hangs as well.


> ManagementContext can leak
> --
>
> Key: ARTEMIS-2111
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2111
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> If a {{management-context}} {{connector}} is configured in {{management.xml}} 
> (e.g. below) and 
> {{org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl#stop(boolean,
>  boolean, boolean)}} is called (e.g. due to criticalIOErrors) the JVM will 
> not exit due to a handful of leaked RMI related threads for the MBean server 
> implementation.
> {code:xml}
> http://activemq.org/schema;>
>
>...
> 
> {code}
> Here's an example thread dump after the broker has stopped:
> {noformat}
> 2018-08-10 10:47:59
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode):
> "Attach Listener" #122 daemon prio=9 os_prio=31 tid=0x7fe609a37800 
> nid=0x920f waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "DestroyJavaVM" #57 prio=5 os_prio=31 tid=0x7fe60a000800 nid=0x1c03 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
>   - None
> "RMI RenewClean-[192.168.1.125:62416]" #20 daemon prio=5 os_prio=31 
> tid=0x7fe609432800 nid=0x7f03 in Object.wait() [0x7672e000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
>   - locked <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
>   at 
> sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:536)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "RMI Scheduler(0)" #19 daemon prio=5 os_prio=31 tid=0x7fe60c2c4000 
> nid=0x7d03 waiting on condition [0x7662b000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x00074017e5b8> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
>   - None
> "GC Daemon" #17 daemon prio=2 os_prio=31 tid=0x7fe60c2bb000 nid=0x7903 in 
> Object.wait() [0x76425000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>   at sun.misc.GC$Daemon.run(GC.java:117)
>   - locked <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>

[jira] [Comment Edited] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon edited comment on AMQ-7072 at 10/15/18 10:34 AM:


This gets a -1 from me (with caveats) as I don't think we should be changing 
the default serializer away from Jackson based on 1 use case when it has been 
used for years by many people.  Also this would definitely not make it into a 
minor version update.

At this point I can't tell if there is a finished implementation yet as it 
looks like it isn't done but not sure. 
https://github.com/FasterXML/jackson-future-ideas/issues/19

If there is a finished version of an implementation for JSON-B then I would 
probably be ok going to JSON-B in the next major update (5.16.0) as long as 
Jackson is the default serializer still and then users can change if they want.


was (Author: christopher.l.shannon):
This gets a -1 from me as I don't think we should be changing the default 
serializer based on 1 use case when it has been used for years by many people.  
Furthermore even if JSON-B were to be used then I would still want to make 
Jackson the default and as far as I can tell there isn't a finished 
implementation yet. https://github.com/FasterXML/jackson-future-ideas/issues/19

Lastly this would definitely not make it into a minor version update.

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon updated AMQ-7072:

Fix Version/s: (was: 5.15.7)

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon edited comment on AMQ-7072 at 10/15/18 10:26 AM:


This gets a -1 from me as I don't think we should be changing the default 
serializer based on 1 use case when it has been used for years by many people.  
Furthermore even if JSON-B were to be used then I would still want to make 
Jackson the default and as far as I can tell there isn't a finished 
implementation yet. https://github.com/FasterXML/jackson-future-ideas/issues/19

Lastly this would definitely not make it into a minor version update.


was (Author: christopher.l.shannon):
This gets a -1 from me as I don't think we should be changing the default 
serializer based on 1 use case when it has been used for years by many people.  
Furthermore even if JSON-B were to be used then I would still want to make 
Jackson the default and as far as I can tell there isn't a finished 
implementation yet. https://github.com/FasterXML/jackson-future-ideas/issues/19

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch

2018-10-15 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-7072:
-

This gets a -1 from me as I don't think we should be changing the default 
serializer based on 1 use case when it has been used for years by many people.  
Furthermore even if JSON-B were to be used then I would still want to make 
Jackson the default and as far as I can tell there isn't a finished 
implementation yet. https://github.com/FasterXML/jackson-future-ideas/issues/19

> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to 
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
>
> The regression we hit at the moment is that activemq enforces TomEE to import 
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B 
> spec is out and implemented by both I guess it can be the way to solve that 
> issue.
> The most blocking thing is 
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
>  - which can already not create a mapper if json is empty ;) - but here is 
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
>  com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
>  com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
>  com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (AMQ-7075) Camel tests failure

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on AMQ-7075:
-

GitHub user jbonofre opened a pull request:

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

[AMQ-7075] Fix Camel test (userName instead of username)



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

$ git pull https://github.com/jbonofre/activemq AMQ-7075

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

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


commit e22703edc6974f705d29f1f88ff5fd879e3a9fe9
Author: Jean-Baptiste Onofré 
Date:   2018-10-15T09:31:43Z

[AMQ-7075] Fix Camel test (userName instead of username)




> Camel tests failure
> ---
>
> Key: AMQ-7075
> URL: https://issues.apache.org/jira/browse/AMQ-7075
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Couple of Camel tests are failing:
> {code}
>   
> ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
>   
> ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
>  » BeanCreation
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

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

https://github.com/apache/activemq-artemis/pull/2371#discussion_r225093373
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQAddressBlockedException.java
 ---
@@ -0,0 +1,24 @@
+/*
+ * 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.api.core;
+
+public class ActiveMQAddressBlockedException extends ActiveMQException {
+
+   public ActiveMQAddressBlockedException(String address) {
--- End diff --

To help the JVM to handle this exception like a "common" case (and not 
exceptional): i suggest to disable the stack trace generation for this 
exception by adding:
```
@Override
public Throwable fillInStackTrace() {
return this;
} 
```
That would allow to create `ActiveMQAddressBlockedException` as a singleton 
and just reusing it a signal.

I'm assuming that the use case for pause/block producers is making 
intensive use of this exception as an event that allow recovering and deciding 
what to do next in the common execution path.


> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (AMQ-7075) Camel tests failure

2018-10-15 Thread JIRA
Jean-Baptiste Onofré created AMQ-7075:
-

 Summary: Camel tests failure
 Key: AMQ-7075
 URL: https://issues.apache.org/jira/browse/AMQ-7075
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-camel
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré


Couple of Camel tests are failing:

{code}
  
ActiveMQComponentFactoryUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
 » BeanCreation
  
ActiveMQComponentUserNamePasswordTest>CamelTestSupport.setUp:279->CamelSpringTestSupport.doPreSetup:80->CamelSpringTestSupport.doCreateApplicationContext:90->createApplicationContext:30
 » BeanCreation
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2123) Paging not stopped if there are no consumers on one subscription

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2123:
-

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

https://github.com/apache/activemq-artemis/pull/2369#discussion_r225077165
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageCursorProviderImpl.java
 ---
@@ -599,6 +600,29 @@ private long checkMinPage(Collection 
cursorList) {
 
}
 
+   private void deliverIfNecessary(Collection 
cursorList) {
+  long minPage = Long.MAX_VALUE;
+  PageSubscription slowSubscription = null;
+  int nonEmptyCursorNum = 0;
+
+  for (PageSubscription cursor : cursorList) {
+ long firstPage = cursor.getFirstPage();
+
+ // the cursor will return -1 if the cursor is empty
+ if (firstPage >= 0) {
+nonEmptyCursorNum++;
+if (firstPage < minPage) {
+   minPage = firstPage;
+   slowSubscription = cursor.getQueue().getMessageCount() == 0 
? cursor : null;
+}
+ }
+  }
+
+  if (nonEmptyCursorNum > 1 && slowSubscription != null) {
--- End diff --

@wy96f nice! So please change the code with the refined version of 
`deliverIfNecessary` and squash the commits into one :+1: 


> Paging not stopped if there are no consumers on one subscription
> 
>
> Key: ARTEMIS-2123
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2123
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.6.3
>Reporter: yangwei
>Priority: Major
>
> Reproduction steps:
>  # create a topic t and two subscriptions ta, tb
>  # send messages to ta and tb
>  # create ta consumers and receive all messages from ta
>  # close consumers
>  # only send message to tb
>  # create tb consumers and receive all message from tb
>  # topic not stopped paging



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2097) Pause and Block Producers

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2097:
-

GitHub user gaohoward opened a pull request:

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

ARTEMIS-2097 Pause and Block Producers

Added new methods to AddressControl and ServerControl to allow users
to block sending on addresses. Once blocked, any messages sending
to the blocked addresses will get rejected with an exception. The
senders can catch the corresponding exception and handle properly.
For example, keep resending or send messages to some alternative
addresses.

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

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

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

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


commit 056e09b036ffe4eb0022328a837cfa8ec7c28203
Author: Howard Gao 
Date:   2018-10-15T08:10:31Z

ARTEMIS-2097 Pause and Block Producers

Added new methods to AddressControl and ServerControl to allow users
to block sending on addresses. Once blocked, any messages sending
to the blocked addresses will get rejected with an exception. The
senders can catch the corresponding exception and handle properly.
For example, keep resending or send messages to some alternative
addresses.




> Pause and Block Producers
> -
>
> Key: ARTEMIS-2097
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2097
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.5.5
> Environment: AMQ-1.5.5
>Reporter: Tyronne Wickramarathne
>Assignee: Howard Gao
>Priority: Major
> Fix For: unscheduled
>
>
> Could it be possible to block all incoming messages without changing the 
> address-full-policy to 'BLOCK'?
> The address full policy can be configured to block incoming messages should 
> the address full policy reaches the configured max-size-bytes attributes.
> However, on certain circumstances it is important to make a JMS destination 
> drain without accepting incoming messages while keeping the 
> address-full-policy at 'PAGE'. For an instance, if a user needs to bring down 
> the broker for maintenance, it is important to allow the user to drain 
> existing messages in the corresponding destination without accepting any new 
> messages.
>  
> Currently the pause() method on a destination pauses message consumers. In a 
> similar fashion could it be possible to add a new method to block message 
> producers on a given destination irrespective of the address-full-policy 
> being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1929) Cannot have two durable consumers on the same queue (STOMP)

2018-10-15 Thread Lionel Cons (JIRA)


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

Lionel Cons updated ARTEMIS-1929:
-
Attachment: ARTEMIS-1929.log

> Cannot have two durable consumers on the same queue (STOMP)
> ---
>
> Key: ARTEMIS-1929
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1929
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
> Attachments: ARTEMIS-1929.log
>
>
> When testing STOMP durable subscriptions, I got errors when having more that 
> one consumer on the same "queue" (i.e. with the same topic, {{client-id}} and 
> {{durable-subscription-name}}).
> Artemis reports:
> {code}
> 2018-06-13 11:27:45,548 WARN  
> [org.apache.activemq.artemis.core.protocol.stomp] AMQ222069: Sent ERROR frame 
> to STOMP client /127.0.0.1:45694: AMQ339016 Error creating subscription 
> 2836570-5b20e391-7fb0-a81b-1
> {code}
> Here is my setup:
>  * two STOMP consumers (different connections)
>  * using the same topic name, {{client-id}} and {{durable-subscription-name}} 
> triplet
> I got this when trying to reproduce what we use with ActiveMQ 5 virtual 
> queues, that is:
>  * producers sending to a topic
>  * different virtual queues attached (e.g. "test" and "prod")
>  * multiple concurrent consumers on each queue to split the consuming load



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1929) Cannot have two durable consumers on the same queue (STOMP)

2018-10-15 Thread Lionel Cons (JIRA)


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

Lionel Cons commented on ARTEMIS-1929:
--

See the attached log. The two consumers run in parallel, in two separate 
threads.

> Cannot have two durable consumers on the same queue (STOMP)
> ---
>
> Key: ARTEMIS-1929
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1929
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
> Attachments: ARTEMIS-1929.log
>
>
> When testing STOMP durable subscriptions, I got errors when having more that 
> one consumer on the same "queue" (i.e. with the same topic, {{client-id}} and 
> {{durable-subscription-name}}).
> Artemis reports:
> {code}
> 2018-06-13 11:27:45,548 WARN  
> [org.apache.activemq.artemis.core.protocol.stomp] AMQ222069: Sent ERROR frame 
> to STOMP client /127.0.0.1:45694: AMQ339016 Error creating subscription 
> 2836570-5b20e391-7fb0-a81b-1
> {code}
> Here is my setup:
>  * two STOMP consumers (different connections)
>  * using the same topic name, {{client-id}} and {{durable-subscription-name}} 
> triplet
> I got this when trying to reproduce what we use with ActiveMQ 5 virtual 
> queues, that is:
>  * producers sending to a topic
>  * different virtual queues attached (e.g. "test" and "prod")
>  * multiple concurrent consumers on each queue to split the consuming load



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-2125) Queue preference changes to display columns not persistent through page refresh

2018-10-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-2125:
-

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/2370
  
I'll take a look at this today


> Queue preference changes to display columns not persistent through page 
> refresh
> ---
>
> Key: ARTEMIS-2125
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2125
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: 2.6.3
>Reporter: Tadayoshi Sato
>Priority: Major
>
> When using the Hawtio web console, we change the default column list in 
> Queues using the arrow in the top right-hand corner. The change in which 
> columns to display does not persist when the page is refreshed, nor does it 
> persist if the page is added to a Dashboard.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)