[jira] [Commented] (AMQ-6067) OutOfMemoryError when expiring big amount of topic messages

[Ganesan (JIRA)]

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

Ganesan commented on AMQ-6067:
--

We still see this problem with 5.13.2, The outofmemory happens whenever I set 
the expiremessages other than 0. When I set to 0 and run the test  no OOO and 
also GC activity looks good.

The other problem we see the durable topics does not seem to be getting cleaned 
up from active_msgs even if I set expiremessages to 6 or 9.

> OutOfMemoryError when expiring big amount of topic messages
> ---
>
> Key: AMQ-6067
> URL: https://issues.apache.org/jira/browse/AMQ-6067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.10.0
>Reporter: Petr Havránek
>  Labels: durable, durable_subscription, expiration, jdbc, 
> timeToLive,
>
> There is a problem in
> {noformat}
> org.apache.activemq.broker.region.Topic.expireMessagesTask
> {noformat}
> When there are big amount of topic messages that are going to be expired, 
> this {{expireMessagesTask}} loads all of the messages to memory. This causes
> {noformat}
> 2015-11-24 11:05:46.359 WARN  [ActiveMQ Broker[JmsEngineActivemqBroker] 
> Scheduler] [Topic] Failed to browse Topic: test-topic
> java.lang.OutOfMemoryError: Java heap space
>   at oracle.sql.BLOB.getBytes(BLOB.java:204)
>   at oracle.jdbc.driver.T4CBlobAccessor.getBytes(T4CBlobAccessor.java:464)
>   at 
> oracle.jdbc.driver.OracleResultSetImpl.getBytes(OracleResultSetImpl.java:676)
>   at 
> org.apache.commons.dbcp.DelegatingResultSet.getBytes(DelegatingResultSet.java:203)
>   at 
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.getBinaryData(DefaultJDBCAdapter.java:80)
>   at 
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doRecover(DefaultJDBCAdapter.java:418)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>   at $Proxy14.doRecover(Unknown Source)
>   at 
> org.apache.activemq.store.jdbc.JDBCMessageStore.recover(JDBCMessageStore.java:236)
>   at 
> org.apache.activemq.store.ProxyTopicMessageStore.recover(ProxyTopicMessageStore.java:62)
>   at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:594)
>   at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65)
>   at org.apache.activemq.broker.region.Topic$6.run(Topic.java:733)
>   at 
> org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
>   at java.util.TimerThread.mainLoop(Timer.java:512)
>   at java.util.TimerThread.run(Timer.java:462)
> {noformat}
> The problem happens when using JDBC persistency with ActiveMQ 5.10.0. After a 
> short look to source code, the same problem could be also with 5.12.1.
> Test case:
> - run ActiveMQ broker with JDBC persistency
> - create subscription to a topic, but do not receive the messages
> - send enough number of messages with short TimeToLive
> - when expireMessagesTask is scheduled, it tries to load all of the messages 
> and causes the OutOfMemoryError
> It would be fine if
> {noformat}
> org.apache.activemq.store.jdbc.JDBCMessageStore.recover(MessageRecoveryListener)
> {noformat}
> will be updated like this:
> {code:java}
> public void recover(final MessageRecoveryListener listener) throws Exception {
>   // Get all the Message ids out of the database.
>   TransactionContext c = persistenceAdapter.getTransactionContext();
>   try {
> c = persistenceAdapter.getTransactionContext();
> adapter.doRecover(c, destination, new JDBCMessageRecoveryListener() {
>   public boolean recoverMessage(long sequenceId, byte[] data) throws 
> Exception {
> if (listener.hasSpace()) {
>   Message msg = (Message)wireFormat.unmarshal(new ByteSequence(data));
>   msg.getMessageId().setBrokerSequenceId(sequenceId);
>   return 

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-584 fix test


> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-584:


Github user asfgit closed the pull request at:

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


> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Commented] (ARTEMIS-573) Please document the selector support

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-573:


[This bit of 
documentation|http://activemq.apache.org/artemis/docs/1.3.0/filter-expressions.html]
 discusses the filter expression syntax supported by Artemis with a link to the 
JMS JavaDoc that has an exhaustive description of the syntax.

I'll get the Stomp documentation updated.

> Please document the selector support
> 
>
> Key: ARTEMIS-573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-573
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>
> SQL-like selectors used in subscriptions seem to be supported but they are 
> not documented. They are mentioned in several pages (including the 
> "Examples") page but not really documented.
> Idem for their STOMP support. Looking at the code I found out that a 
> {{selector}} header can be used in a {{SUBSCRIBE}} frame.
> It is very important to document the syntax supported by Artemis. From 
> memory, a selector like "foo-bar = 1" is supported in Apollo but not in 
> ActiveMQ 5.x. My tests indicate that Artemis does not support it either but, 
> the syntax being undocumented, I don't know if this is a bug or a feature...



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

[jira] [Assigned] (ARTEMIS-573) Please document the selector support

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-573:
--

Assignee: Justin Bertram

> Please document the selector support
> 
>
> Key: ARTEMIS-573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-573
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> SQL-like selectors used in subscriptions seem to be supported but they are 
> not documented. They are mentioned in several pages (including the 
> "Examples") page but not really documented.
> Idem for their STOMP support. Looking at the code I found out that a 
> {{selector}} header can be used in a {{SUBSCRIBE}} frame.
> It is very important to document the syntax supported by Artemis. From 
> memory, a selector like "foo-bar = 1" is supported in Apollo but not in 
> ActiveMQ 5.x. My tests indicate that Artemis does not support it either but, 
> the syntax being undocumented, I don't know if this is a bug or a feature...



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

[jira] [Commented] (ARTEMIS-419) Consider giving access to snapshots

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-419:


FYI - The [Apache Software Release 
Policy|http://www.apache.org/dev/release.html#what] says, "Do not include any 
links on the project website that might encourage non-developers to download 
and use nightly builds, snapshots, release candidates, or any other similar 
package. The only people who are supposed to know about such packages are the 
people following the dev list (or searching its archives) and thus aware of the 
conditions placed on the package."  Therefore we won't be adding a link to the 
snapshots from https://activemq.apache.org/artemis/download.html.

> Consider giving access to snapshots
> ---
>
> Key: ARTEMIS-419
> URL: https://issues.apache.org/jira/browse/ARTEMIS-419
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Lionel Cons
>Priority: Minor
>
> Apollo gives access to development snapshots (see 
> https://activemq.apache.org/apollo/download.html) which are very useful to 
> test new code before new versions are released.
> Could you please consider giving access to such snapshots for Artemis?



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

[jira] [Commented] (ARTEMIS-616) Use ClusterConnection.call timeout on ReplicationManager flow control timeout

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-616:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-616 Use Call timeout on replication flow control



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

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

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

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


commit 0ce19df359c7e6a7493fda9cd040a8749fa92322
Author: Clebert Suconic 
Date:   2016-07-06T21:35:23Z

ARTEMIS-616 Use Call timeout on replication flow control




> Use ClusterConnection.call timeout on ReplicationManager flow control timeout
> -
>
> Key: ARTEMIS-616
> URL: https://issues.apache.org/jira/browse/ARTEMIS-616
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.4.0
>
>




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

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-584:


GitHub user jbertram opened a pull request:

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

ARTEMIS-584 fix test



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

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

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

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


commit ab48c31a2be9de4c0512f0f7e090c6939e1d8c2a
Author: jbertram 
Date:   2016-07-06T21:34:53Z

ARTEMIS-584 fix test




> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Created] (ARTEMIS-616) Use ClusterConnection.call timeout on ReplicationManager flow control timeout

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-616:
---

 Summary: Use ClusterConnection.call timeout on ReplicationManager 
flow control timeout
 Key: ARTEMIS-616
 URL: https://issues.apache.org/jira/browse/ARTEMIS-616
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Affects Versions: 1.3.0
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 1.4.0






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

[jira] [Updated] (ARTEMIS-581) Add setting to control global disk usage

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-581:
---
Affects Version/s: 1.3.0
 Priority: Blocker  (was: Major)
Fix Version/s: 1.4.0

> Add setting to control global disk usage  
> -
>
> Key: ARTEMIS-581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-581
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Priority: Blocker
> Fix For: 1.4.0
>
>
> AFAIK, there is no way to prevent Artemis from using too much space on the 
> disk (with paged messages).
> Disk space, just like memory space, is limited and Artemis should detect when 
> it is about to use too much space and act accordingly (i.e. DROP, FAIL...).
> ActiveMQ 5.x does allow controlling disk usage via its {{storeUsage}} and 
> {{tempUsage}} settings in {{systemUsage}}.
> Could Artemis also use a global disk setting to limit its disk usage?



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

[jira] [Updated] (ARTEMIS-580) Add setting to control global memory usage

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-580:
---
Affects Version/s: 1.3.0

> Add setting to control global memory usage
> --
>
> Key: ARTEMIS-580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-580
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Priority: Blocker
> Fix For: 1.4.0
>
>
> AFAIK, the only way to prevent Artemis from consuming all the heap and dying 
> with OOM errors is to set {{max-size-bytes}}.
> This per-address setting is not suitable for brokers with many addresses that 
> have different usage patterns. For instance, on a broker used for testing, 
> Artemis complained that:
> {code}
> 2016-06-20 13:20:03,107 [org.apache.activemq.artemis.core.server] WARN 
> AMQ05: OutOfMemoryError possible! There are currently 400 addresses with 
> a total max-size-bytes of 4,194,304,000 bytes, but the maximum memory 
> available is 764,411,904 bytes.
> {code}
> These 400 addresses are not used anymore and will eventually be removed.
> In contrast, ActiveMQ 5.x has a much more useful global setting to control 
> how much memory (in total) the broker will use. See {{memoryUsage}} in 
> http://activemq.apache.org/producer-flow-control.html.
> Could Artemis also use a global memory setting to limit its memory usage?
> What to do when hitting this limit (DROP, BLOCK, PAGE...) could stay 
> per-address.



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

[jira] [Updated] (ARTEMIS-580) Add setting to control global memory usage

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-580:
---
 Priority: Blocker  (was: Major)
Fix Version/s: 1.4.0

> Add setting to control global memory usage
> --
>
> Key: ARTEMIS-580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-580
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Priority: Blocker
> Fix For: 1.4.0
>
>
> AFAIK, the only way to prevent Artemis from consuming all the heap and dying 
> with OOM errors is to set {{max-size-bytes}}.
> This per-address setting is not suitable for brokers with many addresses that 
> have different usage patterns. For instance, on a broker used for testing, 
> Artemis complained that:
> {code}
> 2016-06-20 13:20:03,107 [org.apache.activemq.artemis.core.server] WARN 
> AMQ05: OutOfMemoryError possible! There are currently 400 addresses with 
> a total max-size-bytes of 4,194,304,000 bytes, but the maximum memory 
> available is 764,411,904 bytes.
> {code}
> These 400 addresses are not used anymore and will eventually be removed.
> In contrast, ActiveMQ 5.x has a much more useful global setting to control 
> how much memory (in total) the broker will use. See {{memoryUsage}} in 
> http://activemq.apache.org/producer-flow-control.html.
> Could Artemis also use a global memory setting to limit its memory usage?
> What to do when hitting this limit (DROP, BLOCK, PAGE...) could stay 
> per-address.



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

[jira] [Resolved] (ARTEMIS-578) Enable certificate-based authn and authz for STOMP

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-578.

   Resolution: Fixed
Fix Version/s: 1.4.0

> Enable certificate-based authn and authz for STOMP
> --
>
> Key: ARTEMIS-578
> URL: https://issues.apache.org/jira/browse/ARTEMIS-578
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> This is a follow up of ARTEMIS-529.
> Using the newly added dual authentication, my test program fails to 
> authenticate. I get:
> {code}
> 2016-06-20 09:19:40,563 
> [org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager] 
> INFO Couldn't validate user: user name is null
> {code}
> The same program (with the exact same credentials) works fine against an 
> ActiveMQ 5.x broker.



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

[jira] [Commented] (ARTEMIS-578) Enable certificate-based authn and authz for STOMP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-578:


Github user asfgit closed the pull request at:

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


> Enable certificate-based authn and authz for STOMP
> --
>
> Key: ARTEMIS-578
> URL: https://issues.apache.org/jira/browse/ARTEMIS-578
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> This is a follow up of ARTEMIS-529.
> Using the newly added dual authentication, my test program fails to 
> authenticate. I get:
> {code}
> 2016-06-20 09:19:40,563 
> [org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager] 
> INFO Couldn't validate user: user name is null
> {code}
> The same program (with the exact same credentials) works fine against an 
> ActiveMQ 5.x broker.



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

[jira] [Commented] (ARTEMIS-578) Enable certificate-based authn and authz for STOMP

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-578 cert authn/z for STOMP


> Enable certificate-based authn and authz for STOMP
> --
>
> Key: ARTEMIS-578
> URL: https://issues.apache.org/jira/browse/ARTEMIS-578
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> This is a follow up of ARTEMIS-529.
> Using the newly added dual authentication, my test program fails to 
> authenticate. I get:
> {code}
> 2016-06-20 09:19:40,563 
> [org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager] 
> INFO Couldn't validate user: user name is null
> {code}
> The same program (with the exact same credentials) works fine against an 
> ActiveMQ 5.x broker.



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

[jira] [Comment Edited] (ARTEMIS-611) STOMP 1.0 consumers are killed after some time

[Justin Bertram (JIRA)]

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

Justin Bertram edited comment on ARTEMIS-611 at 7/6/16 4:03 PM:


A balance needs to be struck here.  The broker needs to protect itself against 
misbehaving clients who don't close their resources (including STOMP 1.0 
clients) and yet also support reasonable use-cases.

The time-out here is configurable as discussed in [the 
documentation|http://activemq.apache.org/artemis/docs/1.3.0/connection-ttl.html].
  By tuning the {{connection-ttl-override}} you should be able to strike the 
right balance between supporting your STOMP 1.0 clients and also protecting the 
broker.  Is that sufficient for your needs?  If not, please be specific about 
what would be necessary.


was (Author: jbertram):
A balance needs to be struck here.  The broker needs to protect itself against 
misbehaving clients who don't close their resources (including STOMP 1.0 
clients) and yet also support reasonable use-cases.

The time-out here is configurable as discussed in [the 
documentation|http://activemq.apache.org/artemis/docs/1.3.0/connection-ttl.html].
  By tuning the {{connection-ttl-override}} you should be able to achieve 
strike the right balance between supporting your STOMP 1.0 clients and also 
protecting the broker.  Is that sufficient for your needs?  If not, please be 
specific about what would be necessary.

> STOMP 1.0 consumers are killed after some time
> --
>
> Key: ARTEMIS-611
> URL: https://issues.apache.org/jira/browse/ARTEMIS-611
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>
> With the default configuration, a STOMP 1.0 consumer that subscribes to a 
> destination and waits for messages to come gets killed after some time (in 
> case there are no messages coming).
> The broker logs:
> {code}
> 2016-07-04 09:34:31,260 [org.apache.activemq.artemis.core.server] WARN 
> AMQ222067: Connection failure has been detected: AMQ119014: Did not receive 
> data from /192.168.47.193:54716. It is likely the client has exited or 
> crashed without closing its connection, or the network between the server and 
> client has failed. You also might have configured connection-ttl and 
> client-failure-check-period incorrectly. Please check user manual for more 
> information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
> 2016-07-04 09:34:31,261 [org.apache.activemq.artemis.core.server] WARN 
> AMQ222061: Client connection failed, clearing up resources for session 
> 9ae78c80-41b9-11e6-8647-02163e018512
> 2016-07-04 09:34:31,263 [org.apache.activemq.artemis.core.server] WARN 
> AMQ222107: Cleared up resources for session 
> 9ae78c80-41b9-11e6-8647-02163e018512
> {code}
> STOMP 1.0 clients do not support heart-beats and the broker should not kill 
> connections after some period of inactivity.



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

[jira] [Commented] (AMQ-6345) [MQTT] ping response without CONNECT

[ASF subversion and git services (JIRA)]

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

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

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

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

The MQTT transport will now throw an exception if a PINGREQ is sent to
the broker if a CONNECT packet has not been received first as the spec
says CONNECT must be the first packet sent.

(cherry picked from commit 6dacef1c9552edbad656c31d784179c2cd179b2e)


> [MQTT] ping response without CONNECT
> 
>
> Key: AMQ-6345
> URL: https://issues.apache.org/jira/browse/AMQ-6345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.13.3
> Environment: Ubuntu Linux 14.04 
>Reporter: Martin Tappler
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
>
> I am currently investigating the behavior of several MQTT brokers and noticed 
> that the ActiveMQ broker responds to PINGREQ packets with PINGRESP packets 
> even if no CONNECT packet has been sent before. 
> This would be a violation of MQTT-3.1.0-1 and MQTT-4.8.0-1 of MQTT v3.1.1 
> while MQTT v3.1 is not that strict about this issue, but does also state 
> "When a TCP/IP socket connection is established from a client to a server, a 
> protocol level session must be created using a CONNECT flow." 
> (http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect)
> Since ActiveMQ supports MQTT v3.1 according to http://activemq.apache.org/,
> but also MQTT v3.1.1 according to Issue AMQ-4990, I am not sure whether this 
> should actually be considered a bug. 



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

[jira] [Resolved] (AMQ-6345) [MQTT] ping response without CONNECT

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon resolved AMQ-6345.
-
   Resolution: Fixed
Fix Version/s: 5.13.4
   5.14.0

Fixed, an error will now occur for both 3.1 and 3.1.1 if a CONNECT packet 
hasn't been received first.

> [MQTT] ping response without CONNECT
> 
>
> Key: AMQ-6345
> URL: https://issues.apache.org/jira/browse/AMQ-6345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.13.3
> Environment: Ubuntu Linux 14.04 
>Reporter: Martin Tappler
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
>
> I am currently investigating the behavior of several MQTT brokers and noticed 
> that the ActiveMQ broker responds to PINGREQ packets with PINGRESP packets 
> even if no CONNECT packet has been sent before. 
> This would be a violation of MQTT-3.1.0-1 and MQTT-4.8.0-1 of MQTT v3.1.1 
> while MQTT v3.1 is not that strict about this issue, but does also state 
> "When a TCP/IP socket connection is established from a client to a server, a 
> protocol level session must be created using a CONNECT flow." 
> (http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect)
> Since ActiveMQ supports MQTT v3.1 according to http://activemq.apache.org/,
> but also MQTT v3.1.1 according to Issue AMQ-4990, I am not sure whether this 
> should actually be considered a bug. 



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

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-584:


Github user asfgit closed the pull request at:

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


> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Commented] (AMQ-5426) ActiveMQMessageConsumer could run into NPE due to concurrent access to internal state

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon commented on AMQ-5426:
-

5.14.0 might be a little while still but I'm hoping to do a 5.13.4 release next 
week.

> ActiveMQMessageConsumer could run into NPE due to concurrent access to 
> internal state
> -
>
> Key: AMQ-5426
> URL: https://issues.apache.org/jira/browse/AMQ-5426
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.8.0, 5.9.1, 5.10.0
>Reporter: Michael Wong
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
> Attachments: AMQ5426Test.java
>
>
> ActiveMQMessageConsumer could run into NPE when the consumer is closing and a 
> message arrived at the same time.
> Here is the stacktrace:
> java.lang.NullPointerException
> at 
> org.apache.activemq.ActiveMQMessageConsumer.ackLater(ActiveMQMessageConsumer.java:979)
> at 
> org.apache.activemq.ActiveMQMessageConsumer.afterMessageIsConsumed(ActiveMQMessageConsumer.java:929)
> at 
> org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1323)
> at 
> org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)
> at 
> org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)
> at 
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)



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

[jira] [Assigned] (AMQ-6345) [MQTT] ping response without CONNECT

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon reassigned AMQ-6345:
---

Assignee: Christopher L. Shannon

> [MQTT] ping response without CONNECT
> 
>
> Key: AMQ-6345
> URL: https://issues.apache.org/jira/browse/AMQ-6345
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.13.3
> Environment: Ubuntu Linux 14.04 
>Reporter: Martin Tappler
>Assignee: Christopher L. Shannon
>Priority: Minor
>
> I am currently investigating the behavior of several MQTT brokers and noticed 
> that the ActiveMQ broker responds to PINGREQ packets with PINGRESP packets 
> even if no CONNECT packet has been sent before. 
> This would be a violation of MQTT-3.1.0-1 and MQTT-4.8.0-1 of MQTT v3.1.1 
> while MQTT v3.1 is not that strict about this issue, but does also state 
> "When a TCP/IP socket connection is established from a client to a server, a 
> protocol level session must be created using a CONNECT flow." 
> (http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect)
> Since ActiveMQ supports MQTT v3.1 according to http://activemq.apache.org/,
> but also MQTT v3.1.1 according to Issue AMQ-4990, I am not sure whether this 
> should actually be considered a bug. 



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

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-584:


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

https://github.com/apache/activemq-artemis/pull/621#discussion_r69742648
  
--- Diff: docs/user-manual/en/security.md ---
@@ -10,6 +10,13 @@ long. To change this period set the property
 `security-invalidation-interval`, which is in milliseconds. The default
 is `1` ms.
 
+To assist in security auditing the `populate-validated-user` option 
exists. If this is `true` then
+the server will add the name of the validated user to the message using 
the key `_AMQ_VALIDATED_USER`.
+For JMS and Stomp clients this is mapped to the key `JMSXUserID`. For 
users authenticated based on
+their SSL certificate this name is the name to which their certificate's 
DN maps. If `security-enabled`
+is `false` and `populate-validated-user` is `true` then the server will 
simply use whatever user name
+(if any) the client provides. This option is `false` by default.
+
--- End diff --

Done.


> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Commented] (ARTEMIS-584) Add an option to populate JMSXUserID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-584:


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

https://github.com/apache/activemq-artemis/pull/621#discussion_r69741235
  
--- Diff: docs/user-manual/en/security.md ---
@@ -10,6 +10,13 @@ long. To change this period set the property
 `security-invalidation-interval`, which is in milliseconds. The default
 is `1` ms.
 
+To assist in security auditing the `populate-validated-user` option 
exists. If this is `true` then
+the server will add the name of the validated user to the message using 
the key `_AMQ_VALIDATED_USER`.
+For JMS and Stomp clients this is mapped to the key `JMSXUserID`. For 
users authenticated based on
+their SSL certificate this name is the name to which their certificate's 
DN maps. If `security-enabled`
+is `false` and `populate-validated-user` is `true` then the server will 
simply use whatever user name
+(if any) the client provides. This option is `false` by default.
+
--- End diff --

only thing missing is adding this to configuration-index.md, can you do it?


> Add an option to populate JMSXUserID
> 
>
> Key: ARTEMIS-584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-584
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> ActiveMQ 5.x can be configured to set JMSXUserID to the authenticated user, 
> see http://activemq.apache.org/jmsxuserid.html.
> This feature is very important for auditing purposes, to find out who sent a 
> given message.
> Please add a similar functionality to Artemis, including with STOMP mapping.



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

[jira] [Updated] (AMQNET-554) Added support for message properties and selectors in Apache.NMS.MSMQ

[Stephane Ramet (JIRA)]

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

Stephane Ramet updated AMQNET-554:
--
Summary: Added support for message properties and selectors in 
Apache.NMS.MSMQ  (was: Added support for message properties and Selectors in 
Apache.NMS.MSMQ)

> Added support for message properties and selectors in Apache.NMS.MSMQ
> -
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
>  Issue Type: New Feature
>  Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
>  Labels: features, patch
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.7z, 2016-07-05 - 
> Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom 
> message properties in the MSMQ Message.Extension field, along with the 
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be 
> populated with the NMSType (as currently - default value) or with the value 
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID) 
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least - 
> two limitations:
> - it cannot be fully included in the build chains: the source code is 
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by 
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now 
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support 
> for namespace {}), the generated code must be rectified manually. A port to 
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in 
> the queue, via MessageQueue.GetMessageEnumerator2(), and retrieving only the 
> matching messages via MessageQueue.ReceiveByLookupId. When the queue gets 
> very long and the relevant messages are sparse, performance becomes an issue.



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

[jira] [Updated] (AMQNET-554) Added support for message properties and Selectors in Apache.NMS.MSMQ

[Stephane Ramet (JIRA)]

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

Stephane Ramet updated AMQNET-554:
--
Summary: Added support for message properties and Selectors in 
Apache.NMS.MSMQ  (was: Added support for message queue properties and Selectors 
in Apache.NMS.MSMQ)

> Added support for message properties and Selectors in Apache.NMS.MSMQ
> -
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
>  Issue Type: New Feature
>  Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
>  Labels: features, patch
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.7z, 2016-07-05 - 
> Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom 
> message properties in the MSMQ Message.Extension field, along with the 
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be 
> populated with the NMSType (as currently - default value) or with the value 
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID) 
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least - 
> two limitations:
> - it cannot be fully included in the build chains: the source code is 
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by 
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now 
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support 
> for namespace {}), the generated code must be rectified manually. A port to 
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in 
> the queue, via MessageQueue.GetMessageEnumerator2(), and retrieving only the 
> matching messages via MessageQueue.ReceiveByLookupId. When the queue gets 
> very long and the relevant messages are sparse, performance becomes an issue.



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

[jira] [Updated] (AMQNET-554) Added support for message queue properties and Selectors in Apache.NMS.MSMQ

[Stephane Ramet (JIRA)]

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

Stephane Ramet updated AMQNET-554:
--
Attachment: 2016-07-05 - Apache.NMS.MSMQ.patch

> Added support for message queue properties and Selectors in Apache.NMS.MSMQ
> ---
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
>  Issue Type: New Feature
>  Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
>  Labels: features, patch
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom 
> message properties in the MSMQ Message.Extension field, along with the 
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be 
> populated with the NMSType (as currently - default value) or with the value 
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID) 
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least - 
> two limitations:
> - it cannot be fully included in the build chains: the source code is 
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by 
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now 
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support 
> for namespace {}), the generated code must be rectified manually. A port to 
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in 
> the queue, via MessageQueue.GetMessageEnumerator2(), and retrieving only the 
> matching messages via MessageQueue.ReceiveByLookupId. When the queue gets 
> very long and the relevant messages are sparse, performance becomes an issue.



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

[jira] [Created] (AMQNET-554) Added support for message queue properties and Selectors in Apache.NMS.MSMQ

[Stephane Ramet (JIRA)]

Stephane Ramet created AMQNET-554:
-

 Summary: Added support for message queue properties and Selectors 
in Apache.NMS.MSMQ
 Key: AMQNET-554
 URL: https://issues.apache.org/jira/browse/AMQNET-554
 Project: ActiveMQ .Net
  Issue Type: New Feature
  Components: MSMQ
Affects Versions: 1.8.0
Reporter: Stephane Ramet
Assignee: Jim Gomes
Priority: Minor


The proposed package implements the following enhancements :

1. Support for communication of message properties between compatible peers
The DefaultMessageConverter has been enhanced, so as to marshall custom message 
properties in the MSMQ Message.Extension field, along with the NMSCorrelationID 
which was already marshalled in this field.
An additional flag specifies whether the MSMQ Message.Label field should be 
populated with the NMSType (as currently - default value) or with the value of 
a message property called "Label".

2. Support for selectors
A parser for selection strings has been introduced.
It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
MessageReaders have been developped, that support various types of filtering:
- no filtering when no selector strings are specified.
- filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID) or 
LookupId properties.
- filtering based on any other valid selection string.
MessageReaders have been introduced in MessageConsumers and QueueBrowsers.

The generic filtering system, based on a selection string, has - at least - two 
limitations:
- it cannot be fully included in the build chains: the source code is generated 
from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by CSharpCC 
(https://github.com/deveel/csharpcc, a port of JavaCC, now unmaintained). Due 
to limitations and/or bugs in the CSharpCC (eg. support for namespace {}), the 
generated code must be rectified manually. A port to another parser generator 
(eg. ANTLR) would certainly be required.
- selection is performed by the client, by browsing through the messages in the 
queue, via MessageQueue.GetMessageEnumerator2(), and retrieving only the 
matching messages via MessageQueue.ReceiveByLookupId. When the queue gets very 
long and the relevant messages are sparse, performance becomes an issue.



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

[jira] [Created] (ARTEMIS-615) Prompt users if they are browsing documentation for older release

[Jiri Danek (JIRA)]

Jiri Danek created ARTEMIS-615:
--

 Summary: Prompt users if they are browsing documentation for older 
release
 Key: ARTEMIS-615
 URL: https://issues.apache.org/jira/browse/ARTEMIS-615
 Project: ActiveMQ Artemis
  Issue Type: New Feature
Affects Versions: 1.4.0
Reporter: Jiri Danek


Opening documentation for an older Artemis release does not give any indication 
that there is a never release available. 
https://activemq.apache.org/artemis/docs/1.0.0/index.html

It seems to be customary to add a note to older documentations notifying users 
that there is a never version available and a quick menu to switch between 
documentation versions. For example, any readthedocs.io site like buildbot: 
http://buildbot.readthedocs.io/en/v0.8.9/tutorial/docker.html or Postgres: 
https://www.postgresql.org/docs/9.2/static/index.html



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