[GitHub] activemq-artemis pull request #1686: ARTEMIS-1534 added openwire logging (tr...

[pgfox]

GitHub user pgfox opened a pull request:

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

ARTEMIS-1534 added openwire logging (trace level) to log openwire commands


 that are received/sent by the broker. This is similar to the CORE protocol 
packet level logging in 
org/apache/activemq/artemis/core/protocol/core/impl/ChannelImpl.java and 
org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java

  

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

$ git pull https://github.com/pgfox/activemq-artemis openwire_logging

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

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


commit 813f5b459f465effa75883f37e851550c2132adc
Author: Pat Fox 
Date:   2017-12-02T11:10:38Z

ARTEMIS-1534 added openwire logging (trace level) to log openwire commands 
that are received/sent by the broker




---

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Francois Papon]

+1 (non-binding)

Francois


Le 05/12/2017 à 00:32, Clebert Suconic a écrit :
> Following on from the discussion, "[DISCUSS] Confusion surrounding the
> ActiveMQ project roadmap"
>
> linked here for convenience :
> - 
> http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4732935.html
> - 
> http://activemq.2283324.n4.nabble.com/Re-DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4733148.html
>
>
> I would like to propose a vote on ActiveMQ Artemis mainline becoming ActiveMQ 
> 6.
>
> [+1] -  agree
> [-1] . - disagree and provide some reason
> [0] - neutral but go ahead
>
> This vote will be open until Thursday, Dec 07 by the end of the day.
>
> Here is my +1 (PMC) vote.

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Michael André Pearce]

+1 (non-binding)

Cheers
Mike

> On 4 Dec 2017, at 20:32, Clebert Suconic  wrote:
> 
> Following on from the discussion, "[DISCUSS] Confusion surrounding the
> ActiveMQ project roadmap"
> 
> linked here for convenience :
> - 
> http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4732935.html
> - 
> http://activemq.2283324.n4.nabble.com/Re-DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4733148.html
> 
> 
> I would like to propose a vote on ActiveMQ Artemis mainline becoming ActiveMQ 
> 6.
> 
> [+1] -  agree
> [-1] . - disagree and provide some reason
> [0] - neutral but go ahead
> 
> This vote will be open until Thursday, Dec 07 by the end of the day.
> 
> Here is my +1 (PMC) vote.

[VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Clebert Suconic]

Following on from the discussion, "[DISCUSS] Confusion surrounding the
ActiveMQ project roadmap"

linked here for convenience :
- 
http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4732935.html
- 
http://activemq.2283324.n4.nabble.com/Re-DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4733148.html


I would like to propose a vote on ActiveMQ Artemis mainline becoming ActiveMQ 6.

[+1] -  agree
[-1] . - disagree and provide some reason
[0] - neutral but go ahead

This vote will be open until Thursday, Dec 07 by the end of the day.

Here is my +1 (PMC) vote.

[GitHub] activemq-artemis issue #1679: ARTEMIS-1523 Allow MQTT with dynamic cluster

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1679
  
> For what I have analysed in the artemis code, the 
message-load-balancing-type is only set for queues configured in the broker.xml.

I don't believe that's true.  If you change your example to create 
subscriptions on "test/1/some/la" instead of "test/+/some/#" and also remove 
the addresses> block from the broker.xml files then the address 
"test/1/some/la" will be created along with the corresponding subscription 
queues automatically when the client runs.  In this situation I can see that 
the messages are load-balanced properly among the cluster nodes.  This leads me 
to believe that the issue is with how the subscription queues with wildcards 
(i.e. "test/+/some/#") are interacting with the messages send to a specific 
address (i.e. "test/1/some/la").


---

Re: Active MQ docker image

[imranrazakhan]

Hi,

Any news for Official docker image for ActiveMQ?

Regards,



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

[GitHub] activemq-artemis issue #1659: ARTEMIS-1516 - Ensure JNDI via Tomcat Resource...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1659
  
Thats fine with me :) , i was just doing and updating you, that i just 
pushed the example and the docs i promised.


---

[GitHub] activemq-artemis issue #1659: ARTEMIS-1516 - Ensure JNDI via Tomcat Resource...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1659
  
I am working on some compatibility tests I will add into master.. and I 
will then merge this!


---

[GitHub] activemq-artemis pull request #1684: ARTEMIS-1498: Openwire internal headers...

[clebertsuconic]

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

https://github.com/apache/activemq-artemis/pull/1684#discussion_r154658085
  
--- Diff: 
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/CoreAmqpConverter.java
 ---
@@ -95,7 +95,7 @@
 public class CoreAmqpConverter {
 
private static Logger logger = 
Logger.getLogger(CoreAmqpConverter.class);
-
+   public static final String INTERNAL_HEADER = "__HDR_";
--- End diff --

+1


---

[GitHub] activemq-artemis issue #1659: ARTEMIS-1516 - Ensure JNDI via Tomcat Resource...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1659
  
@clebertsuconic i have added a document page now, and also contributed in 
the example i had separately into the examples section.


---

[GitHub] activemq-artemis pull request #1684: ARTEMIS-1498: Openwire internal headers...

[michaelandrepearce]

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

https://github.com/apache/activemq-artemis/pull/1684#discussion_r154642682
  
--- Diff: 
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/CoreAmqpConverter.java
 ---
@@ -95,7 +95,7 @@
 public class CoreAmqpConverter {
 
private static Logger logger = 
Logger.getLogger(CoreAmqpConverter.class);
-
+   public static final String INTERNAL_HEADER = "__HDR_";
--- End diff --

This should be within the OpenWire protocol module and code, should avoid 
protocols specifics leaking into other protocol modules / code area's


---

[GitHub] activemq-artemis issue #1684: ARTEMIS-1498: Openwire internal headers should...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1684
  
If this is specific to OpenWire headers, should this not be stripped during 
converting open wire messages within the open wire protocol support module, it 
shouldn't be leaking into other protocols.


---

[GitHub] activemq-artemis issue #1679: ARTEMIS-1523 Allow MQTT with dynamic cluster

[Skiler]

Github user Skiler commented on the issue:

https://github.com/apache/activemq-artemis/pull/1679
  
Hi @jbertram 

For what I have analysed in the artemis code, the 
message-load-balancing-type is only set for queues configured in the broker.xml.
When you publish to an auto created queue it seems the load balancing type 
isn't set by the postoffice.
So can you help me understand how this is supposed to work in order to fix 
it? I can do this without using the address and using the value defined in the 
default cluster connection. What do you think?

Thanks in advance



---

Re: Contribute a properties-based SQL Provider

[Martyn Taylor]

Hi Jeff,

I think I much prefer this approach of keeping the database specific logic
(i.e. the SQL statements) separate from the implementation.  This would
allow us to have a pure JDBC API + SQL implementation, and adding support
for a new vendor would just be a case of dropping in a new properties
file.  I've taken a look at what you've done and I much prefer it to our
generic SQL provider implementation.

I'd still like to be able to extend the properties impl, as some vendors do
offer their own APIs to manage things like large objects, which I assume,
are highly optimised over the JDBC API.  How about we replace all our impls
(expect the postgres file impl) with what you have here and make the
properties based driver the default?  We can then override this with
implementations that use the optimised APIs by passing the driver class to
the config?  We still need to ensure that our connections are managed in
the same way, but other than that I think it should be relatively straight
forward.  Let me know if you need any help with this.

Nice work!
Martyn



On Thu, Nov 30, 2017 at 2:59 PM, Jeff Mesnil  wrote:

> Hi,
>
> We have integrated Artemis 1.x in WildFly application server with a
> different SQLProvider implementation to support Artemis JDBC store.
> The issue we had at the time with Artemis SQLProvider was that
> supporting a new databases required to add a new class to specify its
> specific JDBC statements and ultimately require new releases for each
> new DB we wanted to test & support.
>
> To circumvent this issue, we wrote a SQLProvider[1] to use for Artemis
> JDBC store that is using a Properties file[2] and a simple overridding
> mechanism to provide DB-specific statements.
> For example to support Oracle DB, Artemis mechanism required to write
> (and maintain) this class:
> https://github.com/apache/activemq-artemis/blob/master/
> artemis-jdbc-store/src/main/java/org/apache/activemq/
> artemis/jdbc/store/drivers/oracle/Oracle12CSQLProvider.java
>
> Using our property-based implementation, we only need to add 2 lines
> to the properties file:
>
> https://github.com/wildfly/wildfly/blob/master/feature-
> pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/
> messaging-activemq/main/database/journal-sql.properties#L43-L45
>
> When the SQLProvider will be queried for a SQL statement, it will
> first searched for a DB-specific dialect and falls back to a generic
> one else:
>
> https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java#L249
>
> The dialect itself is determined used DataSource properties and metadata:
>
> https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java#L85
>
> In addition, this properties file can be easily modified by users
> without requiring a new release to support another database.
>
> We have started development on WildFly 12 and I am looking to
> integrate Artemis 2.4.x.
> I don't want to have to maintain a 2nd implementation of the SQL
> provider in WildFly codebase and I really think that our
> properties-based approach is sounder than the current Artemis
> implementation.
>
> I'd like to propose to contribute back this properties-based SQL
> provider to Artemis codebase in replacement to its current
> implementation. I think this would be beneficial for Artemis as it
> would reduce the amount of work to support a new DB, reduce the number
> of classes for a better maintainability and, of course, ease the
> integration of Artemis into WildFly.
>
> What do you think?
>
> jeff
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging-
> activemq/src/main/java/org/wildfly/extension/messaging/activemq/
> PropertySQLProviderFactory.java
> [2] https://github.com/wildfly/wildfly/blob/master/feature-
> pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/
> messaging-activemq/main/database/journal-sql.properties
> --
> Jeff Mesnil
> jmes...@gmail.com
> http://jmesnil.net/weblog/
>

[GitHub] activemq-artemis pull request #1685: ARTEMIS-1533 Import subschema's so XMLL...

[michaelandrepearce]

GitHub user michaelandrepearce opened a pull request:

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

ARTEMIS-1533 Import subschema's so XMLLINT validates broker.xml



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

$ git pull https://github.com/michaelandrepearce/activemq-artemis 
ARTEMIS-1533

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

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


commit 26e04dfeb2d8c33bfb4eefc34d71e2257770f988
Author: Michael André Pearce 
Date:   2017-12-04T11:38:37Z

ARTEMIS-1533 Import subschema's so XMLLINT validates broker.xml




---

[GitHub] activemq-artemis pull request #1684: ARTEMIS-1498: Openwire internal headers...

[jdanekrh]

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

https://github.com/apache/activemq-artemis/pull/1684#discussion_r154599253
  
--- Diff: 
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/CoreAmqpConverter.java
 ---
@@ -95,7 +95,7 @@
 public class CoreAmqpConverter {
 
private static Logger logger = 
Logger.getLogger(CoreAmqpConverter.class);
-
+   public static final String INTERNAL_HEADER = "__HDR_";
--- End diff --

I am thinking whether this variable should have a broader scope and be 
consistently used instead of the string constant. I know of at least one other 
such place, the `__HDR_` stripping code in 
https://github.com/apache/activemq-artemis/pull/1320/files.


---

[GitHub] activemq-artemis pull request #1684: ARTEMIS-1498: Openwire internal headers...

[RaiSaurabh]

GitHub user RaiSaurabh opened a pull request:

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

ARTEMIS-1498: Openwire internal headers should not be part of message…

… properties

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

$ git pull https://github.com/RaiSaurabh/activemq-artemis header

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

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


commit 563df5d0563d280c2657a4e788a22d980c31af9c
Author: saurabhrai 
Date:   2017-12-04T09:20:26Z

ARTEMIS-1498: Openwire internal headers should not be part of message 
properties




---

[GitHub] activemq-artemis issue #1683: ARTEMIS-1532 Enable tests which are unintentio...

[jdanekrh]

Github user jdanekrh commented on the issue:

https://github.com/apache/activemq-artemis/pull/1683
  
Well, I might've guessed the intent wrong in one or two cases, I guess.

If I thought it is unintentional, I've either renamed the class (so that 
Surefire would pick it) or added the @Test annotation.

If I thought it is intentional, I've added @Ignored annotation instead of 
whichever other method was used to disable that test.


---