[GitHub] activemq-artemis issue #1697: ARTEMIS-1341 fix test for getBytes

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1697
  
@jdanekrh cheers, makes perfect and very obvious sense. *slaps hand against 
forehead and smashes it on table* it’s been a long few days.


---

Artemis client pinned to 1 of 2 brokers when attempting to connect

[Arthur Naseef]

Note that I'm doing much of this for the first time, and not finding
examples on the website, so I expect there's a good chance I'm missing
something.

Summary of the problem:
   * Clients get pinned to a single broker url when attempting to connect,
when using infinite connect attempts.

Background:
I'm attempting to setup the Artemis client in a way that will get
parity with the AMQ 5.x failover transport's default operation (without
optional configuration settings) using static broker urls:

* Client is configured with 2 (possibly more) broker URLs
* Brokers are configured to run active/passive
* All connection failures hidden from the client code; that is:
* Application blocks indefinitely on JMS operations when connection
to broker is down
* Application never gets an exception when the connection to the
broker is down
* Log messages recorded when connections lost and recreated


Artemis client setup:
import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;

ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("broker-url: tcp://localhost:61616#tcp://
localhost:61617");

connectionFactory.setInitialConnectAttempts(-1); // Inifinite
connectionFactory.setReconnectAttempts(-1); // Infinite
connectionFactory.setMaxRetryInterval(1000); // 1 second


Test steps:
* All brokers are SHUTDOWN
* Start the client
* Start either broker


Expected:
* Client reliably connects to the broker that starts, within the
max-reconnect period


Actual:
* Client only connects sometimes; other times, it remains disconnected
indefinitely


Diagnosing:
* Using the debugger and reading the code, found the following key
points in the code:

ServerLocatorImpl.java:771
TransportConfiguration tc = selectConnector();
ClientSessionFactoryImpl.java:1086
Connector liveConnector = createConnector(connectorFactory,
connectorConfig);
NettyConnector.java:575
* host and port

* The host and port in the Netty Connector remain the same on every
call.  The retry logic is in ClientSessionFactoryImpl, which does not have
access to reselect the connector.  In other words, the client gets Pinned
to the one broker url.
* Changing the initialConnectAttempts() to a small value, it is
possible to see that the selectConnector will get called, and choose the
other broker url, after reconnect.  However, this means connection failures
will cause exceptions thrown to the application.


If my findings appear to be incorrect, please let me know and help me to
correct them.  Otherwise, please let me know and I should be able to work
toward getting a fix.

Art

[GitHub] activemq-artemis pull request #1698: ARTEMIS-1547 support referrals in LDAP ...

[jbertram]

GitHub user jbertram opened a pull request:

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

ARTEMIS-1547 support referrals in LDAP login module



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

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

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

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


commit ab587e43657474cff56fcf529149498a0c3a03a7
Author: Justin Bertram 
Date:   2017-12-08T20:06:09Z

ARTEMIS-1547 support referrals in LDAP login module




---

Re: [DISCUSS] Move PR discussions to another list...

[Arthur Naseef]

Thanks Michael.

On Fri, Dec 8, 2017 at 10:52 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Just to clear on my comment much earlier on, it’s my feeling about it
> only. I’m not strongly opinionated thus I didn’t -1 or +1 it, maybe I
> should have +0 it, I personally wouldn’t change it, but if the group wants
> to I won’t be upset either.
>
> it’s email after all I’m sure and i can always subscribe to an extra list.
>
>
>
> Sent from my iPhone
>
> > On 7 Dec 2017, at 17:25, artnaseef  wrote:
> >
> > For all the folks arguing that change is not needed - let me ask a
> question.
> >
> > Is the concern clear?
> >
> > I thought Clebert's post showing the mailing list did a good job, but we
> can
> > talk more about the concern.
> >
> >
> >
> > --
> > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> f2368404.html
>

[GitHub] activemq-artemis issue #1697: ARTEMIS-1341 fix test for getBytes

[jdanekrh]

Github user jdanekrh commented on the issue:

https://github.com/apache/activemq-artemis/pull/1697
  
> Likewise i don't understand why OpenWire is skipped

Skipping OpenWire is appropriate here, as 
[`Message#getBody`](https://docs.oracle.com/javaee/7/api/javax/jms/Message.html#getBody-java.lang.Class-)
 was added in JMS 2.0, and activemq-client implements only the 1.1 version of 
the JMS spec.


---

Re: [DISCUSS] Move PR discussions to another list...

[Michael André Pearce]

Just to clear on my comment much earlier on, it’s my feeling about it only. I’m 
not strongly opinionated thus I didn’t -1 or +1 it, maybe I should have +0 it, 
I personally wouldn’t change it, but if the group wants to I won’t be upset 
either.

it’s email after all I’m sure and i can always subscribe to an extra list.



Sent from my iPhone

> On 7 Dec 2017, at 17:25, artnaseef  wrote:
> 
> For all the folks arguing that change is not needed - let me ask a question.
> 
> Is the concern clear?
> 
> I thought Clebert's post showing the mailing list did a good job, but we can
> talk more about the concern.
> 
> 
> 
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Yes.  I had been chatting with Michael for a while about website updates.
We had a bit of back and forth with this design.  Code is always a good
place to start.  Cheers.

On Fri, Dec 8, 2017 at 2:16 PM, Bruce Snyder  wrote:

> I agree with the idea of making the site the landing page for all the
> sub-projects within the overall ActiveMQ project.
>
> You should take a look at the message from Michael Andre Pearce to see his
> mockup using the new logo, it's an excellent starting point for a
> discussion. Be sure to follow the instructions in the BUILD.md:
>
> https://github.com/michaelandrepearce/activemq-
> site/blob/master/site/BUILD.md
>
> Bruce
>
> On Fri, Dec 8, 2017 at 3:48 AM, Martyn Taylor  wrote:
>
> > Some ideas to kick off design discussion.
> >
> > Really what I am trying to convey here is that ActiveMQ is the home of a
> > more than just 5.x series.  And to have clear links to each project,
> > clicking through would take you to landing page for the project.  This
> > essentially would be the landing page for top level ActiveMQ.
> >
> > I realise the text in the message needs more work (it's also probably
> > worth having a bit of info for each project on the landing page too).
> >
> > On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder 
> > wrote:
> >
> >> This looks great, Michael. It's also a great proof-of-concept, nice
> work.
> >> I
> >> like the look of it, but I don't think we want to completely copy the
> >> Metron site, so we will need to change it up.
> >>
> >> I'm working on getting the exported HTML from the ActiveMQ Confluence
> >> space
> >> and I will dump it into a new git repo.
> >>
> >> Bruce
> >>
> >> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
> >> michael.andre.pea...@me.com> wrote:
> >>
> >> > Agree on jekyll.
> >> >
> >> > Here’s a sample I’ve mocked up with an activemq look and feel (and
> much
> >> > lighter) based around the new logo
> >> >
> >> > https://github.com/michaelandrepearce/activemq-site/tree/master/site
> >> >
> >> > I forked from metrons to get most of the bits like Jekyll etc which is
> >> > already working.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Sent from my iPhone
> >> >
> >> > > On 7 Dec 2017, at 16:49, Bruce Snyder 
> wrote:
> >> > >
> >> > > I would prefer to use Markdown with the Jekyll framework (
> >> > > https://jekyllrb.com/). Jekyll handles Markdown, it handles CSS
> (via
> >> > SASS)
> >> > > and it would allow the site to live in a git repo.
> >> > >
> >> > > Also, I found that other projects use Jekyll with great success,
> here
> >> is
> >> > > just one example in the Flink project:
> >> > >
> >> > > https://flink.apache.org/
> >> > >
> >> > > Nice looking site, clearly more modern and fully customizable.
> >> > >
> >> > > Bruce
> >> > >
> >> > > On Thu, Dec 7, 2017 at 9:42 AM, Clebert Suconic <
> >> > clebert.suco...@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> +1
> >> > >>
> >> > >> I like the Markdown (or whatever easy format.. non xml based). We
> >> will
> >> > >> need to choose a framework for that. do you have anything in mind?
> >> > >>
> >> > >> I also think we should have a consistent look and feel.
> >> > >>
> >> > >>
> >> > >> I will be supportive on this...
> >> > >>
> >> > >>
> >> > >> First thing will be to have a framework chosen..
> >> > >> Second to have a github we collaborate...
> >> > >> Third.. maybe we could use one of those video calls to talk about
> >> how to
> >> > >> do it.
> >> > >>
> >> > >> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder <
> >> bruce.sny...@gmail.com>
> >> > >> wrote:
> >> > >>> Several opinions have been expressed recently that the ActiveMQ
> >> website
> >> > >>> needs some attention and that Artemis should be made more
> prominent.
> >> > I'd
> >> > >>> like to discuss some ideas to see what we could achieve on this
> >> topic.
> >> > >>>
> >> > >>> If we are going to make Artemis more prominent, the first concern
> I
> >> > >>> identified is that the ActiveMQ website and the Artemis website
> are
> >> > >>> authored differently. The ActiveMQ website is authored in the
> >> > Confluence
> >> > >>> wiki and exported to HTML automagically whereas the Artemis
> website
> >> is
> >> > >>> authored in raw HTML. As a result, the two sites have a very
> >> different
> >> > >> look
> >> > >>> and feel to them. This presents some challenges to using the
> content
> >> > >>> between the two.
> >> > >>>
> >> > >>> But this presents other questions -- do we want the two sites to
> >> look
> >> > >>> similar or different? When someone looks at Artemis content, do we
> >> want
> >> > >> the
> >> > >>> user to immediately know that they are looking at ActiveMQ content
> >> vs.
> >> > >>> Artemis based content solely due to the look and feel of the site?
> >> > Should
> >> > >>> there even be two different sites?
> >> > >>>
> >> > >>> I would prefer to have the site authored in a language that is
> 

[GitHub] activemq-artemis issue #1696: NO-JIRA fixed minor regression and broken test...

[pgfox]

Github user pgfox commented on the issue:

https://github.com/apache/activemq-artemis/pull/1696
  
Hi @RaiSaurabh, great work on #1628. 

One minor point, the JSON field name changes as part of that PR causes a 
test to fail. That sparked the conversation above with Mike. It is not a 
problem, I am currently updating this PR to change back to the original names. 
I just wanted to check if there was a "real" requirement for these field 
name changes, perhaps I am overlooking it. 

Thanks in advance.



---

[GitHub] activemq-artemis pull request #1695: ARTEMIS-1545 Ensure JMS security except...

[michaelandrepearce]

Github user michaelandrepearce closed the pull request at:

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


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@clebertsuconic yup thats the idea, i think, instead of this PR (e.g. i 
would close it), we look to sort SendAcknowledgementHandler instead. 


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@michaelandrepearce ok.. but I wouldn't change these defaults


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@clebertsuconic i think the point here is to get the exception back on the 
SendAcknowledgementHandler async then at least a either you can set an 
ExceptionListener to log these out in JMS (for JMS 1.1. methods) , and also 
allow for if a CompletionListener (for JMS 2.0 methods) is set on exception it 
can be passed to the listener.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
We could get exceptions packets back to the client... and cache there so 
any further asynchronous calls would fail with an exception...

Danger of that is.. it's easy to make a test where it fails...


```java
   producer.send(nonPersistent);
   connectionOnSameProducer.createSession(somethingElse); <<< Exception: 
Cannot send message!!! 
```

User would be... What???


that's why it was never implemented...


Only real chance to fix this is to make a check at the producer create 
somehow. but that won't fix anonymous producers.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@andytaylor are you able to give any pointers, if we look to the root of 
improving the SendAcknowledgementHandler like @jbertram suggests. You probably 
know the broker bits a bit better?


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[tabish121]

Github user tabish121 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@michaelandrepearce it depends on what other URI options you've set on the 
5.x client, it will at times switch back to sync based on other configuration.  
For alternate reference the Qpid JMS AMQP 1.0 client will also send 
non-persistent messages async by default, errors would be reported to the 
connection exception listener for JMS 1.1 sends and to the CompletionListener 
for JMS 2.0 async sends as one would expect.  


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
At this point I don't even think the broker is even sending anything back.  
It looks to me like the client simply infers success based on no exceptions 
when pushing the message into the transport layer.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
THe last comment was re SendAcknowledgementHandler  improving 


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@jbertram I think that’s where I got to also, just don’t know where to 
start... any advice or tips?


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@tabish121 this isn’t what we found on testing our two other incumbent 
brokers. There is a toggle on one of them to make it not wait and no exceptions 
but you have to actively override the default 


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
I'm not compelled by the "expectations" argument because different users 
have different expectations.  Users from one JMS implementation might have an 
expectation that non-persistent messages are sent synchronously, but any user 
coming from HornetQ, Artemis, or (more importantly, I think) ActiveMQ 5.x  
among others would have the opposite expectation.  This behavior is not defined 
by the spec, and therefore should be well documented so users will be informed 
and can change their expectations (if necessary).

I think the best way forward would be to improve the 
SendAcknowledgementHandler feature in Artemis which serves as the basis for the 
JMS CompletionHandler implementation.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
So I think we need the core layer to handle back exceptions it’s callback 
only seems be success only, anyone got any pointers where to start and how we 
should look to get that so it gets errors back async to pass to the callback 


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[tabish121]

Github user tabish121 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
Actually I was mostly referring to JMS 1.1 sends where many JMS client opt 
to send non-persistent messages async and indeed won't report an error back 
unless you've explicitly configured the client to do so. 



---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
Eg if that worked then we could make use of that here  to get the exception 
without blocking send.




---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
That’s true if you use the JMS 2.0 async send with an on completion 
listener. But this is older 1.1 sync send method.

Note that also there is an issue with the async send also in artemis client 
currently as onException is never called only onAcknowledge as such cannot make 
use of that due to that bug/issue.




---

[GitHub] activemq-artemis pull request #:

[michaelandrepearce]

Github user michaelandrepearce commented on the pull request:


https://github.com/apache/activemq-artemis/commit/26752a7aafa5651e41abf23ac550c6c09bb08287#commitcomment-26142542
  
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java:
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java
 on line 237:
As in it’s a mistake so please feel free to change and send in a pr :)


---

[GitHub] activemq-artemis pull request #:

[michaelandrepearce]

Github user michaelandrepearce commented on the pull request:


https://github.com/apache/activemq-artemis/commit/26752a7aafa5651e41abf23ac550c6c09bb08287#commitcomment-26142537
  
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java:
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java
 on line 237:
Yup! Good spot!


---

Re: Thoughts on refactoring the ActiveMQ website

[Bruce Snyder]

I agree with the idea of making the site the landing page for all the
sub-projects within the overall ActiveMQ project.

You should take a look at the message from Michael Andre Pearce to see his
mockup using the new logo, it's an excellent starting point for a
discussion. Be sure to follow the instructions in the BUILD.md:

https://github.com/michaelandrepearce/activemq-site/blob/master/site/BUILD.md

Bruce

On Fri, Dec 8, 2017 at 3:48 AM, Martyn Taylor  wrote:

> Some ideas to kick off design discussion.
>
> Really what I am trying to convey here is that ActiveMQ is the home of a
> more than just 5.x series.  And to have clear links to each project,
> clicking through would take you to landing page for the project.  This
> essentially would be the landing page for top level ActiveMQ.
>
> I realise the text in the message needs more work (it's also probably
> worth having a bit of info for each project on the landing page too).
>
> On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder 
> wrote:
>
>> This looks great, Michael. It's also a great proof-of-concept, nice work.
>> I
>> like the look of it, but I don't think we want to completely copy the
>> Metron site, so we will need to change it up.
>>
>> I'm working on getting the exported HTML from the ActiveMQ Confluence
>> space
>> and I will dump it into a new git repo.
>>
>> Bruce
>>
>> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>>
>> > Agree on jekyll.
>> >
>> > Here’s a sample I’ve mocked up with an activemq look and feel (and much
>> > lighter) based around the new logo
>> >
>> > https://github.com/michaelandrepearce/activemq-site/tree/master/site
>> >
>> > I forked from metrons to get most of the bits like Jekyll etc which is
>> > already working.
>> >
>> >
>> >
>> >
>> >
>> >
>> > Sent from my iPhone
>> >
>> > > On 7 Dec 2017, at 16:49, Bruce Snyder  wrote:
>> > >
>> > > I would prefer to use Markdown with the Jekyll framework (
>> > > https://jekyllrb.com/). Jekyll handles Markdown, it handles CSS (via
>> > SASS)
>> > > and it would allow the site to live in a git repo.
>> > >
>> > > Also, I found that other projects use Jekyll with great success, here
>> is
>> > > just one example in the Flink project:
>> > >
>> > > https://flink.apache.org/
>> > >
>> > > Nice looking site, clearly more modern and fully customizable.
>> > >
>> > > Bruce
>> > >
>> > > On Thu, Dec 7, 2017 at 9:42 AM, Clebert Suconic <
>> > clebert.suco...@gmail.com>
>> > > wrote:
>> > >
>> > >> +1
>> > >>
>> > >> I like the Markdown (or whatever easy format.. non xml based). We
>> will
>> > >> need to choose a framework for that. do you have anything in mind?
>> > >>
>> > >> I also think we should have a consistent look and feel.
>> > >>
>> > >>
>> > >> I will be supportive on this...
>> > >>
>> > >>
>> > >> First thing will be to have a framework chosen..
>> > >> Second to have a github we collaborate...
>> > >> Third.. maybe we could use one of those video calls to talk about
>> how to
>> > >> do it.
>> > >>
>> > >> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder <
>> bruce.sny...@gmail.com>
>> > >> wrote:
>> > >>> Several opinions have been expressed recently that the ActiveMQ
>> website
>> > >>> needs some attention and that Artemis should be made more prominent.
>> > I'd
>> > >>> like to discuss some ideas to see what we could achieve on this
>> topic.
>> > >>>
>> > >>> If we are going to make Artemis more prominent, the first concern I
>> > >>> identified is that the ActiveMQ website and the Artemis website are
>> > >>> authored differently. The ActiveMQ website is authored in the
>> > Confluence
>> > >>> wiki and exported to HTML automagically whereas the Artemis website
>> is
>> > >>> authored in raw HTML. As a result, the two sites have a very
>> different
>> > >> look
>> > >>> and feel to them. This presents some challenges to using the content
>> > >>> between the two.
>> > >>>
>> > >>> But this presents other questions -- do we want the two sites to
>> look
>> > >>> similar or different? When someone looks at Artemis content, do we
>> want
>> > >> the
>> > >>> user to immediately know that they are looking at ActiveMQ content
>> vs.
>> > >>> Artemis based content solely due to the look and feel of the site?
>> > Should
>> > >>> there even be two different sites?
>> > >>>
>> > >>> I would prefer to have the site authored in a language that is
>> easier
>> > to
>> > >>> write than HTML (such as Markdown). I would also like the files
>> > >> comprising
>> > >>> the site to live in a git repo. To give the site a modern look and
>> feel
>> > >>> means using CSS (e.g., SASS, etc.). All these things can be achieved
>> > >> using
>> > >>> Jekyll, but first we would need to convert the raw HTML files to
>> > Mardown
>> > >> to
>> > >>> put in git. I have experimented with some tools to convert HTML to
>> > >> Markdown
>> > >>> and they are less than ideal. Does anyone 

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[tabish121]

Github user tabish121 commented on the issue:

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


This doesn't actually strike me as being a bug on the send as many JMS 
provider will indeed send the message asynchronously and if any error is 
reported on send fail it'd be done via the JMS ExceptionListener on the 
Connection. It would be nice if the createProducer failed here if not 
authorized to write to the target destination but if using an anonymous 
producer than again this seems to operate as many other JMS clients would.

The standard practice here would be to use a transaction to create a sync 
point (i.e. the commit) where the broker would report the operation as failed 
if any of the sends inside that TX failed for some reason. Since the 
NON_PERSISTENT delivery mode is 'at-most-once' you shouldn't expect the same 
QoS behaviors on the client send (unless of course you can configure that which 
appears you could via the block option).



---

[GitHub] activemq-artemis issue #1697: ARTEMIS-1341 fix test for getBytes

[stanlyDoge]

Github user stanlyDoge commented on the issue:

https://github.com/apache/activemq-artemis/pull/1697
  
This is just test fix. There are some issues with clients. I'll get back to 
it later.


---

Re: Artemis Roadmap

[Christopher Shannon]

Thanks Martyn, ON_DEMAND is what I was looking for.  Clustering is more of
what I want to set up instead of a Core bridge.

On Fri, Dec 8, 2017 at 8:03 AM, Clebert Suconic 
wrote:

> I want to add a dependency to cli.
>
>
> Artemis Kaka-import ...
>
>
> It would use that module at the CLI.
>
>
>
> On Fri, Dec 8, 2017 at 7:19 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> >
> > https://github.com/apache/activemq-cli-tools/tree/
> master/activemq-kahadb-exporter
> >
> > I created that tool a while back but it was my fault for not publicizing
> it
> > more.  We can advertise it on the new web site and as part of the
> migration
> > strategy.  It will export messages to XML from KahaDB and MultiKahaDB and
> > can be filtered by destinations.  It will also compress the XML file if
> > desired.  Artemis can then read in the messages from XML and write them
> to
> > its store.  The nice thing about this is the data can be imported into
> any
> > existing Artemis store (it doesn't have to be a brand new store).
> >
> > MessageId can not be retained right now because Artemis does not support
> > OpenWire as a format for storing messages and the CORE ids are different.
> > (It only supports CORE and AMQP I think)  The OpenWire messages in the
> > KahaDB journal need to be converted to the CORE protocol in order to be
> > imported into Artemis.  However, I believe that the original messageId is
> > at least added as a property to the CORE message so it could be
> referenced
> > later.
> >
> > Before creating this tool I initially looked at seeing if it made sense
> for
> > Artemis to support KahaDB as a store however when I researched it was
> clear
> > that the Artemis journal has a lot of advantages over KahaDB (faster, has
> > compaction and paging, supports replication...to name a few) so it
> doesn't
> > make sense to support it.
> >
> > On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
> > wrote:
> >
> > > FWIW- An offline KahaDB export / Artemis Journal import tool was an
> idea
> > I
> > > added to the wiki page Bruce setup. Maintaining messageId I think is
> the
> > > most critical element, and we could leave behind things like incomplete
> > > transactions, message groups, etc.
> > >
> > >
> > > On 12/7/17 10:00 PM, Clebert Suconic wrote:
> > >
> > >> On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
> > >> wrote:
> > >>
> > >> I have suggested a similar tool that will read the ActiveMQ 5.x XML
> > >>> configuration and convert it to an equivalent Artemis config. I think
> > >>> this
> > >>> would be easier to create than making Artemis read ActiveMQ 5.x
> > configs.
> > >>>
> > >>> For some reason I thought that Artemis supported KahaDB, but I'm not
> > sure
> > >>> where I got this. I thought I read it somewhere. I wonder how
> difficult
> > >>> it
> > >>> would be to make Artemis support KahaDB as it is still the fastest
> > >>> message
> > >>> store, correct?
> > >>>
> > >>> Artemis journal  it’s faster.  We don’t currently support KahaDB.
> > >>
> > >>
> > >>
> > >>
> > >> Bruce
> > >>>
> > >>> On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
> > >>> christopher.l.shan...@gmail.com> wrote:
> > >>>
> > >>> Thanks for getting this started Bruce.
> > 
> >  The migration portion is going to be tricky and we need to discuss
> > more
> > 
> > >>> how
> > >>>
> >  to handle it.  Maybe we need to write a tool to help convert the old
> > 5.x
> >  XML config to the Artemis config or update Artemis to be able to
> read
> > a
> > 
> > >>> 5.x
> > >>>
> >  style config.  Obviously not everything will translate directly so
> > that
> >  would need to be figured out.
> > 
> >  For the datastore we have a tool that will export KahaDB to XML that
> > can
> >  then be imported by Artemis but this could probably be improved even
> >  more
> >  to make it more automated.
> > 
> >  On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram  >
> >  wrote:
> > 
> >  Thanks, Bruce!
> > >
> > >
> > > Justin
> > >
> > > On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder <
> bruce.sny...@gmail.com
> > >
> > > wrote:
> > >
> > > I have added the following statement to the first paragraph in the
> > >>
> > > wiki
> > >>>
> >  page:
> > >>
> > >>  The overall objective for working toward feature parity
> between
> > >> ActiveMQ 5.x and Artemis is for Artemis to eventually become
> > ActiveMQ
> > >>
> > > 6.x.
> > >
> > >> Bruce
> > >>
> > >> On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram <
> jbert...@redhat.com
> > >
> > >> wrote:
> > >>
> > >> Would it be possible to clarify what, if anything, will happen if
> > >>>
> > >> Artemis
> > >
> > >> achieves the described level of feature parity with ActiveMQ 5.x?
> > >>>
> > >> In
> > >>>
> > 

[GitHub] activemq-artemis pull request #:

[stanlyDoge]

Github user stanlyDoge commented on the pull request:


https://github.com/apache/activemq-artemis/commit/26752a7aafa5651e41abf23ac550c6c09bb08287#commitcomment-26140681
  
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java:
In 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSClientTestSupport.java
 on line 237:
@michaelandrepearce Are you sure this line should be 
'createCoreConnection'? For me it would make sense if it was 
'createOpenWireConnection'. It is suspisious that 'createOpenWireConnection' 
method is implemented (overloaded) but never used.


---

Re: Artemis Roadmap

[Clebert Suconic]

I want to add a dependency to cli.


Artemis Kaka-import ...


It would use that module at the CLI.



On Fri, Dec 8, 2017 at 7:19 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

>
> https://github.com/apache/activemq-cli-tools/tree/master/activemq-kahadb-exporter
>
> I created that tool a while back but it was my fault for not publicizing it
> more.  We can advertise it on the new web site and as part of the migration
> strategy.  It will export messages to XML from KahaDB and MultiKahaDB and
> can be filtered by destinations.  It will also compress the XML file if
> desired.  Artemis can then read in the messages from XML and write them to
> its store.  The nice thing about this is the data can be imported into any
> existing Artemis store (it doesn't have to be a brand new store).
>
> MessageId can not be retained right now because Artemis does not support
> OpenWire as a format for storing messages and the CORE ids are different.
> (It only supports CORE and AMQP I think)  The OpenWire messages in the
> KahaDB journal need to be converted to the CORE protocol in order to be
> imported into Artemis.  However, I believe that the original messageId is
> at least added as a property to the CORE message so it could be referenced
> later.
>
> Before creating this tool I initially looked at seeing if it made sense for
> Artemis to support KahaDB as a store however when I researched it was clear
> that the Artemis journal has a lot of advantages over KahaDB (faster, has
> compaction and paging, supports replication...to name a few) so it doesn't
> make sense to support it.
>
> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
> wrote:
>
> > FWIW- An offline KahaDB export / Artemis Journal import tool was an idea
> I
> > added to the wiki page Bruce setup. Maintaining messageId I think is the
> > most critical element, and we could leave behind things like incomplete
> > transactions, message groups, etc.
> >
> >
> > On 12/7/17 10:00 PM, Clebert Suconic wrote:
> >
> >> On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
> >> wrote:
> >>
> >> I have suggested a similar tool that will read the ActiveMQ 5.x XML
> >>> configuration and convert it to an equivalent Artemis config. I think
> >>> this
> >>> would be easier to create than making Artemis read ActiveMQ 5.x
> configs.
> >>>
> >>> For some reason I thought that Artemis supported KahaDB, but I'm not
> sure
> >>> where I got this. I thought I read it somewhere. I wonder how difficult
> >>> it
> >>> would be to make Artemis support KahaDB as it is still the fastest
> >>> message
> >>> store, correct?
> >>>
> >>> Artemis journal  it’s faster.  We don’t currently support KahaDB.
> >>
> >>
> >>
> >>
> >> Bruce
> >>>
> >>> On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
> >>> christopher.l.shan...@gmail.com> wrote:
> >>>
> >>> Thanks for getting this started Bruce.
> 
>  The migration portion is going to be tricky and we need to discuss
> more
> 
> >>> how
> >>>
>  to handle it.  Maybe we need to write a tool to help convert the old
> 5.x
>  XML config to the Artemis config or update Artemis to be able to read
> a
> 
> >>> 5.x
> >>>
>  style config.  Obviously not everything will translate directly so
> that
>  would need to be figured out.
> 
>  For the datastore we have a tool that will export KahaDB to XML that
> can
>  then be imported by Artemis but this could probably be improved even
>  more
>  to make it more automated.
> 
>  On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram 
>  wrote:
> 
>  Thanks, Bruce!
> >
> >
> > Justin
> >
> > On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder  >
> > wrote:
> >
> > I have added the following statement to the first paragraph in the
> >>
> > wiki
> >>>
>  page:
> >>
> >>  The overall objective for working toward feature parity between
> >> ActiveMQ 5.x and Artemis is for Artemis to eventually become
> ActiveMQ
> >>
> > 6.x.
> >
> >> Bruce
> >>
> >> On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram  >
> >> wrote:
> >>
> >> Would it be possible to clarify what, if anything, will happen if
> >>>
> >> Artemis
> >
> >> achieves the described level of feature parity with ActiveMQ 5.x?
> >>>
> >> In
> >>>
>  other
> >>
> >>> words, what is the goal of Artemis' feature parity with 5.x?  I
> >>>
> >> think a
> 
> > broader road-map like that would really help the community as they
> >>>
> >> could
> >
> >> look at the Artemis road-map and see that they can help achieve the
> >>>
> >> goal
> >
> >> (whatever that is) by helping to implement feature X or Y.
> >>>
> >>>
> >>> Justin
> >>>
> >>> On Wed, Dec 6, 2017 at 2:51 PM, Bruce Snyder <
> 

[GitHub] activemq-artemis issue #1696: NO-JIRA fixed minor regression and broken test...

[pgfox]

Github user pgfox commented on the issue:

https://github.com/apache/activemq-artemis/pull/1696
  
@michaelandrepearce  Thanks Mike,

I agree about the field names in the JSON objects; IMHO they are really 
part of the external interface so should not be changed unless there is a very 
good reason.  I will try to revert all names changed in  #1628  and update this 
PR.
 


---

Re: Artemis Roadmap

[Martyn Taylor]

Are you specifically asking about the Core bridge?  Or clustering in
Artemis?

See the message-load-balancing policy on the cluster connection:
https://activemq.apache.org/artemis/docs/2.3.0/clusters.html

I think ON_DEMAND is what you're after.

Cheers

On Fri, Dec 8, 2017 at 12:38 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Clebert (or anyone else familiar with bridges),
>
> Does the core bridge in Artemis support demand based bridging?
>
> One feature I use in 5.x a lot to prevent unnecessary network traffic is to
> have consumers drive the message flow.  I.e. if you have multiple brokers
> bridged together it doesn't make much sense for broker A to send messages
> to broker B if there are no current consumers on broker B (especially for
> topic subscriptions or non-persistent messages)
>
> On Fri, Dec 8, 2017 at 7:20 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > https://github.com/apache/activemq-cli-tools has the main readme which
> > has some usage instructions.  Version 0.1.0 has been released already.
> >
> > On Fri, Dec 8, 2017 at 7:18 AM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> https://github.com/apache/activemq-cli-tools/tree/master/
> >> activemq-kahadb-exporter
> >>
> >> I created that tool a while back but it was my fault for not publicizing
> >> it more.  We can advertise it on the new web site and as part of the
> >> migration strategy.  It will export messages to XML from KahaDB and
> >> MultiKahaDB and can be filtered by destinations.  It will also compress
> the
> >> XML file if desired.  Artemis can then read in the messages from XML and
> >> write them to its store.  The nice thing about this is the data can be
> >> imported into any existing Artemis store (it doesn't have to be a brand
> new
> >> store).
> >>
> >> MessageId can not be retained right now because Artemis does not support
> >> OpenWire as a format for storing messages and the CORE ids are
> different.
> >> (It only supports CORE and AMQP I think)  The OpenWire messages in the
> >> KahaDB journal need to be converted to the CORE protocol in order to be
> >> imported into Artemis.  However, I believe that the original messageId
> is
> >> at least added as a property to the CORE message so it could be
> referenced
> >> later.
> >>
> >> Before creating this tool I initially looked at seeing if it made sense
> >> for Artemis to support KahaDB as a store however when I researched it
> was
> >> clear that the Artemis journal has a lot of advantages over KahaDB
> (faster,
> >> has compaction and paging, supports replication...to name a few) so it
> >> doesn't make sense to support it.
> >>
> >> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
> >> wrote:
> >>
> >>> FWIW- An offline KahaDB export / Artemis Journal import tool was an
> idea
> >>> I added to the wiki page Bruce setup. Maintaining messageId I think is
> the
> >>> most critical element, and we could leave behind things like incomplete
> >>> transactions, message groups, etc.
> >>>
> >>>
> >>> On 12/7/17 10:00 PM, Clebert Suconic wrote:
> >>>
>  On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
>  wrote:
> 
>  I have suggested a similar tool that will read the ActiveMQ 5.x XML
> > configuration and convert it to an equivalent Artemis config. I think
> > this
> > would be easier to create than making Artemis read ActiveMQ 5.x
> > configs.
> >
> > For some reason I thought that Artemis supported KahaDB, but I'm not
> > sure
> > where I got this. I thought I read it somewhere. I wonder how
> > difficult it
> > would be to make Artemis support KahaDB as it is still the fastest
> > message
> > store, correct?
> >
> > Artemis journal  it’s faster.  We don’t currently support KahaDB.
> 
> 
> 
> 
>  Bruce
> >
> > On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > Thanks for getting this started Bruce.
> >>
> >> The migration portion is going to be tricky and we need to discuss
> >> more
> >>
> > how
> >
> >> to handle it.  Maybe we need to write a tool to help convert the old
> >> 5.x
> >> XML config to the Artemis config or update Artemis to be able to
> read
> >> a
> >>
> > 5.x
> >
> >> style config.  Obviously not everything will translate directly so
> >> that
> >> would need to be figured out.
> >>
> >> For the datastore we have a tool that will export KahaDB to XML that
> >> can
> >> then be imported by Artemis but this could probably be improved even
> >> more
> >> to make it more automated.
> >>
> >> On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram  >
> >> wrote:
> >>
> >> Thanks, Bruce!
> >>>
> >>>
> >>> Justin
> >>>
> >>> On Wed, 

Re: Artemis Roadmap

[Christopher Shannon]

Clebert (or anyone else familiar with bridges),

Does the core bridge in Artemis support demand based bridging?

One feature I use in 5.x a lot to prevent unnecessary network traffic is to
have consumers drive the message flow.  I.e. if you have multiple brokers
bridged together it doesn't make much sense for broker A to send messages
to broker B if there are no current consumers on broker B (especially for
topic subscriptions or non-persistent messages)

On Fri, Dec 8, 2017 at 7:20 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> https://github.com/apache/activemq-cli-tools has the main readme which
> has some usage instructions.  Version 0.1.0 has been released already.
>
> On Fri, Dec 8, 2017 at 7:18 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> https://github.com/apache/activemq-cli-tools/tree/master/
>> activemq-kahadb-exporter
>>
>> I created that tool a while back but it was my fault for not publicizing
>> it more.  We can advertise it on the new web site and as part of the
>> migration strategy.  It will export messages to XML from KahaDB and
>> MultiKahaDB and can be filtered by destinations.  It will also compress the
>> XML file if desired.  Artemis can then read in the messages from XML and
>> write them to its store.  The nice thing about this is the data can be
>> imported into any existing Artemis store (it doesn't have to be a brand new
>> store).
>>
>> MessageId can not be retained right now because Artemis does not support
>> OpenWire as a format for storing messages and the CORE ids are different.
>> (It only supports CORE and AMQP I think)  The OpenWire messages in the
>> KahaDB journal need to be converted to the CORE protocol in order to be
>> imported into Artemis.  However, I believe that the original messageId is
>> at least added as a property to the CORE message so it could be referenced
>> later.
>>
>> Before creating this tool I initially looked at seeing if it made sense
>> for Artemis to support KahaDB as a store however when I researched it was
>> clear that the Artemis journal has a lot of advantages over KahaDB (faster,
>> has compaction and paging, supports replication...to name a few) so it
>> doesn't make sense to support it.
>>
>> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
>> wrote:
>>
>>> FWIW- An offline KahaDB export / Artemis Journal import tool was an idea
>>> I added to the wiki page Bruce setup. Maintaining messageId I think is the
>>> most critical element, and we could leave behind things like incomplete
>>> transactions, message groups, etc.
>>>
>>>
>>> On 12/7/17 10:00 PM, Clebert Suconic wrote:
>>>
 On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
 wrote:

 I have suggested a similar tool that will read the ActiveMQ 5.x XML
> configuration and convert it to an equivalent Artemis config. I think
> this
> would be easier to create than making Artemis read ActiveMQ 5.x
> configs.
>
> For some reason I thought that Artemis supported KahaDB, but I'm not
> sure
> where I got this. I thought I read it somewhere. I wonder how
> difficult it
> would be to make Artemis support KahaDB as it is still the fastest
> message
> store, correct?
>
> Artemis journal  it’s faster.  We don’t currently support KahaDB.




 Bruce
>
> On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> Thanks for getting this started Bruce.
>>
>> The migration portion is going to be tricky and we need to discuss
>> more
>>
> how
>
>> to handle it.  Maybe we need to write a tool to help convert the old
>> 5.x
>> XML config to the Artemis config or update Artemis to be able to read
>> a
>>
> 5.x
>
>> style config.  Obviously not everything will translate directly so
>> that
>> would need to be figured out.
>>
>> For the datastore we have a tool that will export KahaDB to XML that
>> can
>> then be imported by Artemis but this could probably be improved even
>> more
>> to make it more automated.
>>
>> On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram 
>> wrote:
>>
>> Thanks, Bruce!
>>>
>>>
>>> Justin
>>>
>>> On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder >> >
>>> wrote:
>>>
>>> I have added the following statement to the first paragraph in the

>>> wiki
>
>> page:

  The overall objective for working toward feature parity between
 ActiveMQ 5.x and Artemis is for Artemis to eventually become
 ActiveMQ

>>> 6.x.
>>>
 Bruce

 On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram 
 wrote:

 Would it be possible to clarify what, if 

Re: Artemis Roadmap

[Christopher Shannon]

https://github.com/apache/activemq-cli-tools has the main readme which has
some usage instructions.  Version 0.1.0 has been released already.

On Fri, Dec 8, 2017 at 7:18 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> https://github.com/apache/activemq-cli-tools/tree/master/activemq-kahadb-
> exporter
>
> I created that tool a while back but it was my fault for not publicizing
> it more.  We can advertise it on the new web site and as part of the
> migration strategy.  It will export messages to XML from KahaDB and
> MultiKahaDB and can be filtered by destinations.  It will also compress the
> XML file if desired.  Artemis can then read in the messages from XML and
> write them to its store.  The nice thing about this is the data can be
> imported into any existing Artemis store (it doesn't have to be a brand new
> store).
>
> MessageId can not be retained right now because Artemis does not support
> OpenWire as a format for storing messages and the CORE ids are different.
> (It only supports CORE and AMQP I think)  The OpenWire messages in the
> KahaDB journal need to be converted to the CORE protocol in order to be
> imported into Artemis.  However, I believe that the original messageId is
> at least added as a property to the CORE message so it could be referenced
> later.
>
> Before creating this tool I initially looked at seeing if it made sense
> for Artemis to support KahaDB as a store however when I researched it was
> clear that the Artemis journal has a lot of advantages over KahaDB (faster,
> has compaction and paging, supports replication...to name a few) so it
> doesn't make sense to support it.
>
> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich 
> wrote:
>
>> FWIW- An offline KahaDB export / Artemis Journal import tool was an idea
>> I added to the wiki page Bruce setup. Maintaining messageId I think is the
>> most critical element, and we could leave behind things like incomplete
>> transactions, message groups, etc.
>>
>>
>> On 12/7/17 10:00 PM, Clebert Suconic wrote:
>>
>>> On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
>>> wrote:
>>>
>>> I have suggested a similar tool that will read the ActiveMQ 5.x XML
 configuration and convert it to an equivalent Artemis config. I think
 this
 would be easier to create than making Artemis read ActiveMQ 5.x configs.

 For some reason I thought that Artemis supported KahaDB, but I'm not
 sure
 where I got this. I thought I read it somewhere. I wonder how difficult
 it
 would be to make Artemis support KahaDB as it is still the fastest
 message
 store, correct?

 Artemis journal  it’s faster.  We don’t currently support KahaDB.
>>>
>>>
>>>
>>>
>>> Bruce

 On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
 christopher.l.shan...@gmail.com> wrote:

 Thanks for getting this started Bruce.
>
> The migration portion is going to be tricky and we need to discuss more
>
 how

> to handle it.  Maybe we need to write a tool to help convert the old
> 5.x
> XML config to the Artemis config or update Artemis to be able to read a
>
 5.x

> style config.  Obviously not everything will translate directly so that
> would need to be figured out.
>
> For the datastore we have a tool that will export KahaDB to XML that
> can
> then be imported by Artemis but this could probably be improved even
> more
> to make it more automated.
>
> On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram 
> wrote:
>
> Thanks, Bruce!
>>
>>
>> Justin
>>
>> On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder 
>> wrote:
>>
>> I have added the following statement to the first paragraph in the
>>>
>> wiki

> page:
>>>
>>>  The overall objective for working toward feature parity between
>>> ActiveMQ 5.x and Artemis is for Artemis to eventually become ActiveMQ
>>>
>> 6.x.
>>
>>> Bruce
>>>
>>> On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram 
>>> wrote:
>>>
>>> Would it be possible to clarify what, if anything, will happen if

>>> Artemis
>>
>>> achieves the described level of feature parity with ActiveMQ 5.x?

>>> In

> other
>>>
 words, what is the goal of Artemis' feature parity with 5.x?  I

>>> think a
>
>> broader road-map like that would really help the community as they

>>> could
>>
>>> look at the Artemis road-map and see that they can help achieve the

>>> goal
>>
>>> (whatever that is) by helping to implement feature X or Y.


 Justin

 On Wed, Dec 6, 2017 at 2:51 PM, Bruce Snyder <

>>> bruce.sny...@gmail.com

> wrote:

 I 

Re: Artemis Roadmap

[Christopher Shannon]

https://github.com/apache/activemq-cli-tools/tree/master/activemq-kahadb-exporter

I created that tool a while back but it was my fault for not publicizing it
more.  We can advertise it on the new web site and as part of the migration
strategy.  It will export messages to XML from KahaDB and MultiKahaDB and
can be filtered by destinations.  It will also compress the XML file if
desired.  Artemis can then read in the messages from XML and write them to
its store.  The nice thing about this is the data can be imported into any
existing Artemis store (it doesn't have to be a brand new store).

MessageId can not be retained right now because Artemis does not support
OpenWire as a format for storing messages and the CORE ids are different.
(It only supports CORE and AMQP I think)  The OpenWire messages in the
KahaDB journal need to be converted to the CORE protocol in order to be
imported into Artemis.  However, I believe that the original messageId is
at least added as a property to the CORE message so it could be referenced
later.

Before creating this tool I initially looked at seeing if it made sense for
Artemis to support KahaDB as a store however when I researched it was clear
that the Artemis journal has a lot of advantages over KahaDB (faster, has
compaction and paging, supports replication...to name a few) so it doesn't
make sense to support it.

On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich  wrote:

> FWIW- An offline KahaDB export / Artemis Journal import tool was an idea I
> added to the wiki page Bruce setup. Maintaining messageId I think is the
> most critical element, and we could leave behind things like incomplete
> transactions, message groups, etc.
>
>
> On 12/7/17 10:00 PM, Clebert Suconic wrote:
>
>> On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder 
>> wrote:
>>
>> I have suggested a similar tool that will read the ActiveMQ 5.x XML
>>> configuration and convert it to an equivalent Artemis config. I think
>>> this
>>> would be easier to create than making Artemis read ActiveMQ 5.x configs.
>>>
>>> For some reason I thought that Artemis supported KahaDB, but I'm not sure
>>> where I got this. I thought I read it somewhere. I wonder how difficult
>>> it
>>> would be to make Artemis support KahaDB as it is still the fastest
>>> message
>>> store, correct?
>>>
>>> Artemis journal  it’s faster.  We don’t currently support KahaDB.
>>
>>
>>
>>
>> Bruce
>>>
>>> On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon <
>>> christopher.l.shan...@gmail.com> wrote:
>>>
>>> Thanks for getting this started Bruce.

 The migration portion is going to be tricky and we need to discuss more

>>> how
>>>
 to handle it.  Maybe we need to write a tool to help convert the old 5.x
 XML config to the Artemis config or update Artemis to be able to read a

>>> 5.x
>>>
 style config.  Obviously not everything will translate directly so that
 would need to be figured out.

 For the datastore we have a tool that will export KahaDB to XML that can
 then be imported by Artemis but this could probably be improved even
 more
 to make it more automated.

 On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram 
 wrote:

 Thanks, Bruce!
>
>
> Justin
>
> On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder 
> wrote:
>
> I have added the following statement to the first paragraph in the
>>
> wiki
>>>
 page:
>>
>>  The overall objective for working toward feature parity between
>> ActiveMQ 5.x and Artemis is for Artemis to eventually become ActiveMQ
>>
> 6.x.
>
>> Bruce
>>
>> On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram 
>> wrote:
>>
>> Would it be possible to clarify what, if anything, will happen if
>>>
>> Artemis
>
>> achieves the described level of feature parity with ActiveMQ 5.x?
>>>
>> In
>>>
 other
>>
>>> words, what is the goal of Artemis' feature parity with 5.x?  I
>>>
>> think a

> broader road-map like that would really help the community as they
>>>
>> could
>
>> look at the Artemis road-map and see that they can help achieve the
>>>
>> goal
>
>> (whatever that is) by helping to implement feature X or Y.
>>>
>>>
>>> Justin
>>>
>>> On Wed, Dec 6, 2017 at 2:51 PM, Bruce Snyder <
>>>
>> bruce.sny...@gmail.com
>>>
 wrote:
>>>
>>> I have created a page on the wiki for the Artemis Roadmap here:

 https://cwiki.apache.org/confluence/display/ACTIVEMQ/
 ActiveMQ+Artemis+Roadmap

 The goal of this page is stated at the top: to identify the

>>> outstanding
>
>> issues that must be addressed by Artemis in order to achieve some

>>> level
>
>> of
>>>
 feature 

[GitHub] activemq-artemis issue #1697: ARTEMIS-1341 fix test for getBytes

[stanlyDoge]

Github user stanlyDoge commented on the issue:

https://github.com/apache/activemq-artemis/pull/1697
  
> Behaviour should be the same
True, there was little misunderstanding. I am working at fix.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@andytaylor the issue i see is that the defaults should err on the side of 
safety imo. 

Having a client not throw any exception and continue blindly is dangerous 
(even if its miss-config). Just because something is like it is, doesn't always 
been it should be.

I get the performance thing, but then thats something someone should make a 
conscious decision to enable at the expense of exceptions.

Just a bit of background, we migrated a flow (it was using JMS api, so 
switch is just in the CF) from another vendor's broker to Artemis, and released 
to prod.

The broker did alert, but the operations team operating the broker saw it 
as a client issue. and as was a client issue they believed the client team 
would also get an error, have been alerted and would have resolved. 
Because the client team had no error, it was not until quite a period later 
it was discovered and external reports had to alert us to the issue.

We re-tested the scenario with our other brokers, and they would have 
alerted client side so this is why this assumption is had.

If we look to other people migrating I'm fairly sure the other brokers we 
use, are quite well used, and as such other users would make similar 
assumptions and expectation that the client would still error by default, 
unless they toggled something for performance on purpose.




---

Re: Thoughts on refactoring the ActiveMQ website

[Martyn Taylor]

Some ideas to kick off design discussion.

Really what I am trying to convey here is that ActiveMQ is the home of a
more than just 5.x series.  And to have clear links to each project,
clicking through would take you to landing page for the project.  This
essentially would be the landing page for top level ActiveMQ.

I realise the text in the message needs more work (it's also probably worth
having a bit of info for each project on the landing page too).

On Fri, Dec 8, 2017 at 1:23 AM, Bruce Snyder  wrote:

> This looks great, Michael. It's also a great proof-of-concept, nice work. I
> like the look of it, but I don't think we want to completely copy the
> Metron site, so we will need to change it up.
>
> I'm working on getting the exported HTML from the ActiveMQ Confluence space
> and I will dump it into a new git repo.
>
> Bruce
>
> On Thu, Dec 7, 2017 at 9:55 AM, Michael André Pearce <
> michael.andre.pea...@me.com> wrote:
>
> > Agree on jekyll.
> >
> > Here’s a sample I’ve mocked up with an activemq look and feel (and much
> > lighter) based around the new logo
> >
> > https://github.com/michaelandrepearce/activemq-site/tree/master/site
> >
> > I forked from metrons to get most of the bits like Jekyll etc which is
> > already working.
> >
> >
> >
> >
> >
> >
> > Sent from my iPhone
> >
> > > On 7 Dec 2017, at 16:49, Bruce Snyder  wrote:
> > >
> > > I would prefer to use Markdown with the Jekyll framework (
> > > https://jekyllrb.com/). Jekyll handles Markdown, it handles CSS (via
> > SASS)
> > > and it would allow the site to live in a git repo.
> > >
> > > Also, I found that other projects use Jekyll with great success, here
> is
> > > just one example in the Flink project:
> > >
> > > https://flink.apache.org/
> > >
> > > Nice looking site, clearly more modern and fully customizable.
> > >
> > > Bruce
> > >
> > > On Thu, Dec 7, 2017 at 9:42 AM, Clebert Suconic <
> > clebert.suco...@gmail.com>
> > > wrote:
> > >
> > >> +1
> > >>
> > >> I like the Markdown (or whatever easy format.. non xml based). We will
> > >> need to choose a framework for that. do you have anything in mind?
> > >>
> > >> I also think we should have a consistent look and feel.
> > >>
> > >>
> > >> I will be supportive on this...
> > >>
> > >>
> > >> First thing will be to have a framework chosen..
> > >> Second to have a github we collaborate...
> > >> Third.. maybe we could use one of those video calls to talk about how
> to
> > >> do it.
> > >>
> > >> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder  >
> > >> wrote:
> > >>> Several opinions have been expressed recently that the ActiveMQ
> website
> > >>> needs some attention and that Artemis should be made more prominent.
> > I'd
> > >>> like to discuss some ideas to see what we could achieve on this
> topic.
> > >>>
> > >>> If we are going to make Artemis more prominent, the first concern I
> > >>> identified is that the ActiveMQ website and the Artemis website are
> > >>> authored differently. The ActiveMQ website is authored in the
> > Confluence
> > >>> wiki and exported to HTML automagically whereas the Artemis website
> is
> > >>> authored in raw HTML. As a result, the two sites have a very
> different
> > >> look
> > >>> and feel to them. This presents some challenges to using the content
> > >>> between the two.
> > >>>
> > >>> But this presents other questions -- do we want the two sites to look
> > >>> similar or different? When someone looks at Artemis content, do we
> want
> > >> the
> > >>> user to immediately know that they are looking at ActiveMQ content
> vs.
> > >>> Artemis based content solely due to the look and feel of the site?
> > Should
> > >>> there even be two different sites?
> > >>>
> > >>> I would prefer to have the site authored in a language that is easier
> > to
> > >>> write than HTML (such as Markdown). I would also like the files
> > >> comprising
> > >>> the site to live in a git repo. To give the site a modern look and
> feel
> > >>> means using CSS (e.g., SASS, etc.). All these things can be achieved
> > >> using
> > >>> Jekyll, but first we would need to convert the raw HTML files to
> > Mardown
> > >> to
> > >>> put in git. I have experimented with some tools to convert HTML to
> > >> Markdown
> > >>> and they are less than ideal. Does anyone have any experience with
> > this?
> > >>>
> > >>> Sorry for the rambling. Anyone else interested to help tackle this
> > thorny
> > >>> set of issues?
> > >>>
> > >>> Bruce
> > >>>
> > >>> --
> > >>> perl -e 'print
> > >>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > );'
> > >>>
> > >>> ActiveMQ in Action: http://bit.ly/2je6cQ
> > >>> Blog: http://bsnyder.org/ 
> > >>> Twitter: http://twitter.com/brucesnyder
> > >>
> > >>
> > >>
> > >> --
> > >> Clebert Suconic
> > >>
> > >
> > >
> > >
> > > --
> > > perl -e 'print
> > > 

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[andytaylor]

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@michaelandrepearce I dont have one :), however I dont see a reason to 
change defaults that have around for such a long time. 


---

[GitHub] activemq-artemis issue #1697: ARTEMIS-1341 fix test for getBytes

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1697
  
Behaviour should be the same, which ever JMS client they use, I'm not in 
favour of behaviours being different, this gives a bad experience to users if 
one client behaves one way and another behaves another. 


---

[GitHub] activemq-artemis pull request #1697: ARTEMIS-1341 fix test for getBytes

[michaelandrepearce]

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

https://github.com/apache/activemq-artemis/pull/1697#discussion_r155747541
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/BodyTest.java
 ---
@@ -59,13 +58,19 @@ public void testBodyConversion() throws Throwable {
  producer.send(bytesMessage);
 
  Message msg = cons.receiveNoWait();
- assertNotNull(msg);
--- End diff --

this should be kept.


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
@andytaylor to propagate exceptions on send (with it being sync) it will 
have to block somewhere, and wait for the return packet, i don't see much other 
options. It be good if there is one you have in mind if you could share.


---

[GitHub] activemq-artemis pull request #1697: ARTEMIS-1341 fix test for getBytes

[stanlyDoge]

GitHub user stanlyDoge opened a pull request:

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

ARTEMIS-1341 fix test for getBytes

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

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

$ git pull https://github.com/stanlyDoge/activemq-artemis-1 ARTEMIS-1341

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

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


commit 5f07d9e93a98ebb112cac46b1bfae352b1747541
Author: Stanislav Knot 
Date:   2017-12-08T09:34:07Z

ARTEMIS-1341 fix test for getBytes




---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[andytaylor]

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
I agree with Justin, I think its a bad idea to change this. we should find 
a different solution if we want to propagate exceptions back to the client. 


---

[GitHub] activemq-artemis issue #1696: NO-JIRA fixed minor regression and broken test...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1696
  
@pgfox Good catch, i think this has picked up a regression in the code, the 
test has done its job in detecting that change, so i don't think we should 
change the test, but correct the change that was done in the field names.


---

[GitHub] activemq-artemis pull request #1696: NO-JIRA fixed minor regression and brok...

[michaelandrepearce]

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

https://github.com/apache/activemq-artemis/pull/1696#discussion_r155725477
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/ActiveMQServerControlTest.java
 ---
@@ -1879,8 +1879,8 @@ public void testListConsumers() throws Exception {
  array = (JsonArray) consumersAsJsonObject.get("data");
 
  Assert.assertEquals("number of consumers returned from query", 2, 
array.size());
- Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(0).getString("address"));
- Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(1).getString("address"));
+ Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(0).getString("queueAddress"));
--- End diff --

Just for my benefit so it links this with the other PR, 
https://github.com/apache/activemq-artemis/pull/1628


---

Re: [DISCUSS] Video call on ActiveMQ Artemis

[Francesco Nigro]

+1 I've had something similar with Clebert in the past and it was very
useful indeed!

Thanks Clebert for this great idea and I agree with Michael that probably I
will follow it in the evening too :)

Cheers,
Franz

Il giorno ven 8 dic 2017 alle ore 02:04 Christopher Shannon <
christopher.l.shan...@gmail.com> ha scritto:

> +1 from me as well.  Recording the session is a great idea for anyone who
> can’t make it
>
> On Thu, Dec 7, 2017 at 6:52 PM artnaseef  wrote:
>
> > +1 Count me in.  Hope I can make it.
> >
> >
> >
> >
> > --
> > Sent from:
> > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
> >
>

[GitHub] activemq-artemis pull request #1696: NO-JIRA fixed minor regression and brok...

[michaelandrepearce]

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

https://github.com/apache/activemq-artemis/pull/1696#discussion_r155723971
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
 ---
@@ -1737,8 +1737,12 @@ public String listAddresses(String options, int 
page, int pageSize) throws Excep
   try {
  final Set addresses = 
server.getPostOffice().getAddresses();
  List addressInfo = new ArrayList<>();
- for (SimpleString address:addresses) {
-
addressInfo.add(server.getPostOffice().getAddressInfo(address));
+ for (SimpleString address : addresses) {
+AddressInfo info = 
server.getPostOffice().getAddressInfo(address);
+//ignore if no longer available
+if (info != null) {
--- End diff --

Nice check.


---

[GitHub] activemq-artemis pull request #1696: NO-JIRA fixed minor regression and brok...

[michaelandrepearce]

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

https://github.com/apache/activemq-artemis/pull/1696#discussion_r155723803
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/ActiveMQServerControlTest.java
 ---
@@ -1879,8 +1879,8 @@ public void testListConsumers() throws Exception {
  array = (JsonArray) consumersAsJsonObject.get("data");
 
  Assert.assertEquals("number of consumers returned from query", 2, 
array.size());
- Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(0).getString("address"));
- Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(1).getString("address"));
+ Assert.assertEquals("check consumers address", 
addressName1.toString(), array.getJsonObject(0).getString("queueAddress"));
--- End diff --

should keep this simply address IMO. 


---

[GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1695
  
I think expected JMS behaviour is more important.

Persistence is about if the message should be persistent during broker 
restart/failure for broker side perfomance. It shouldn't change the behaviour 
of the client in regards to exceptions.

Like wise as a user you would expect client side exception by default (spec 
or no-spec). 

When checking other vendors (We checked out other two brokers) and also 
5.x, exception on send to the broker is thrown back to the client with 
non-persistent. (e.g. no difference between persistent or not in these case)

I think this is particularly important for anyone migrating (and pertinent 
with regards to 5.X users moving) that they would still get JMS exceptions on 
send and not get any surprises that they don't get them. 

FYI this is what we are doing, migrating from several different brokers 
onto Artemis.

On the note of performance (as you may be aware or not) we do care for 
performance (throughput and latency) in our brokers due to nature of the 
business, but expected behaviour (aka no shocks) is more important. On that 
note we actually did do some tests and found produce to consume latency reduced 
per message.

Like wise for those really wanting it and willing to sacrifice no client 
side exceptions they still can set this to false consciously, but the point is 
the default should be that users do expect them, and probably should get such 
surprises. 

 




---