date:20180516

Before someone asks on the VOTE Thread.. I wanted to point out that I
made a small project to parse git commit and generate a report.

I have ran the report on top of artemis and I'm adding a commit report
here that can be useful at least on the voter's thread:

https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.0/artemis-2.6.0.html



I think it would be useful to have this one on top of the release
report as well. If nobody opposes I would like to add it to the next
release report.

The report generator current lives on my github page but it could be
moved somewhere else if someone bothers about being on my github fork:

https://github.com/clebertsuconic/git-release-report

-- 
Clebert Suconic

[VOTE] Apache ActiveMQ Artemis 2.6.0

I would like to propose an Apache ActiveMQ Artemis 2.6.0 release.

The release notes can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342903&=12315920

There is a new commits report I made that I'm introducing on this release:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.0/artemis-2.6.0.html

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.0

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1157

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html

The source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/2.6.0

I will update the website after the vote has passed.


[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1

Re: [HEADS-UP] 2.5.1 in one week

I have been pushing this for a few weeks.  I thought it was more than
clear.  I didn’t mean to get anyone by surprise.

Along the conversation here 2.5.1 will just be renamed as 2.6.0.


I’m traveling today and I wanted to tag and upload from home.  And I wanted
something to do tonight at the hotel :).  Sorry for any trouble.

We can try another one shortly in a few weeks. (2 or 3)

On Wed, May 16, 2018 at 11:53 AM Timothy Bish  wrote:

> On 05/16/2018 11:09 AM, Clebert Suconic wrote:
> > I just tagged as 2.6.0... It's uploading...
> >
> > I will cleanup JIRA tonight / tomorrow.. should send the voting thread
> > soon (tonight or tomorrow)
>
> This seems a bit backwards to me.  I'd think in the future it'd be nice
> to send some notice before you spin the release to give folks some
> warning.  The title of this thread still references a 2.5.1 release in a
> week which are both incorrect so anyone watching for it might miss the
> notice and anyone working on last minute fixes or whatnot gets no notice.
>
> It'd probably be a good idea to do the JIRA cleanup prior to all this as
> a way to better gauge where things stand before pulling the trigger and
> also give people some better insight into what is in the release when
> the vote thread appears.
>
> It probably wouldn't be as big a deal if releases were happening on a
> more frequent basis but given the long delay I'd say some warning next
> time would probably be the courteous thing to do.
>
> > On Thu, May 10, 2018 at 10:33 AM, Clebert Suconic
> >  wrote:
> >> I have been clearing the testsuite. Other guys are working with me on
> >> that (Francesco, Justin for instance). I'll do as soon as I'm done.
> >>
> >> On Thu, May 10, 2018 at 8:24 AM, Christopher Shannon
> >>  wrote:
> >>> +1 to make this a 2.6.0 release, there are now over 80 commits and
> >>> been enough time that I think a 2.6.0 makes more sense
> >>>
> >>> On Thu, May 3, 2018 at 12:09 PM, Clebert Suconic
> >>>  wrote:
>  Meanwhile please set your fixes as 2.5.1... i will rename it as 2.6.0
>  before releasing as everything is already filtered there.
> 
>  On Thu, May 3, 2018 at 12:04 PM, Clebert Suconic
>   wrote:
> >  From the entire set.. we only have fixes.. and 4 enhancements...
> > (previously existent features).
> >
> > I would prefer saving 2.6.0 for a more substantial release.. but if
> > you guys still prefer calling 2.6.0 I'm fine with that.
> >
> > On Thu, May 3, 2018 at 11:02 AM, Robbie Gemmell
> >  wrote:
> >> I see there are some updates retargetting JIRA version at 2.5.1 from
> >> 2.6.0. I think the changes on master are now more suited to the
> >> release being versioned as 2.6.0. There are plenty of changes in the
> >> time since 2.5.0 that would have suited 2.5.x releases, but there
> >> seems to be enough others in there now that might better fit a 2.6.0
> >> due to adding new functionality etc.
> >>
> >> Thoughts?
> >>
> >> Robbie
> >>
> >> On 26 April 2018 at 22:46, Clebert Suconic <
> clebert.suco...@gmail.com> wrote:
> >>> Little snafu today... I'm dealing with a failure in
> >>>
> org.apache.activemq.artemis.tests.integration.openwire.amq.RedeliveryPolicyTest.testRedeliveryPolicyPerDestination
> >>>
> >>> will send the vote soon.
> >>>
> >>> On Wed, Apr 25, 2018 at 9:24 PM, Clebert Suconic
> >>>  wrote:
>  I will cut it tomorrow.  I won’t merge anything until it’s out.
> 
>  @Commiters please don’t break Anything today :)
> 
>  @everyvody if there is anything you want Merged or committed
> tomorrow let me
>  know.
> 
>  On Wed, Apr 25, 2018 at 4:41 PM pwjenkins
>   wrote:
> > Are you on track to release by the end of April?
> >
> >
> >
> > --
> > Sent from:
> > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>  --
>  Clebert Suconic
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >
> >
> > --
> > Clebert Suconic
> 
> 
>  --
>  Clebert Suconic
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> >
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
> --
Clebert Suconic

Re: [HEADS-UP] 2.5.1 in one week

2018-05-16 Thread Timothy Bish

On 05/16/2018 11:09 AM, Clebert Suconic wrote:

I just tagged as 2.6.0... It's uploading...

I will cleanup JIRA tonight / tomorrow.. should send the voting thread
soon (tonight or tomorrow)

This seems a bit backwards to me. I'd think in the future it'd be nice
to send some notice before you spin the release to give folks some
warning. The title of this thread still references a 2.5.1 release in a
week which are both incorrect so anyone watching for it might miss the
notice and anyone working on last minute fixes or whatnot gets no notice.

It'd probably be a good idea to do the JIRA cleanup prior to all this as
a way to better gauge where things stand before pulling the trigger and
also give people some better insight into what is in the release when
the vote thread appears.

It probably wouldn't be as big a deal if releases were happening on a
more frequent basis but given the long delay I'd say some warning next
time would probably be the courteous thing to do.

On Thu, May 10, 2018 at 10:33 AM, Clebert Suconic
wrote:

I have been clearing the testsuite. Other guys are working with me on
that (Francesco, Justin for instance). I'll do as soon as I'm done.

On Thu, May 10, 2018 at 8:24 AM, Christopher Shannon
wrote:

+1 to make this a 2.6.0 release, there are now over 80 commits and
been enough time that I think a 2.6.0 makes more sense

On Thu, May 3, 2018 at 12:09 PM, Clebert Suconic
wrote:

Meanwhile please set your fixes as 2.5.1... i will rename it as 2.6.0
before releasing as everything is already filtered there.

On Thu, May 3, 2018 at 12:04 PM, Clebert Suconic
wrote:

From the entire set.. we only have fixes.. and 4 enhancements...
(previously existent features).

I would prefer saving 2.6.0 for a more substantial release.. but if
you guys still prefer calling 2.6.0 I'm fine with that.

On Thu, May 3, 2018 at 11:02 AM, Robbie Gemmell
wrote:

I see there are some updates retargetting JIRA version at 2.5.1 from
2.6.0. I think the changes on master are now more suited to the
release being versioned as 2.6.0. There are plenty of changes in the
time since 2.5.0 that would have suited 2.5.x releases, but there
seems to be enough others in there now that might better fit a 2.6.0
due to adding new functionality etc.

Thoughts?

Robbie

On 26 April 2018 at 22:46, Clebert Suconic wrote:

Little snafu today... I'm dealing with a failure in
org.apache.activemq.artemis.tests.integration.openwire.amq.RedeliveryPolicyTest.testRedeliveryPolicyPerDestination

will send the vote soon.

On Wed, Apr 25, 2018 at 9:24 PM, Clebert Suconic
wrote:

I will cut it tomorrow. I won’t merge anything until it’s out.

@Commiters please don’t break Anything today :)

@everyvody if there is anything you want Merged or committed tomorrow let me
know.

On Wed, Apr 25, 2018 at 4:41 PM pwjenkins
wrote:

Are you on track to release by the end of April?

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

--
Clebert Suconic

--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: Reword NMS for AMQPNetLite

2018-05-16 Thread Duane Pauls

To clarify, Ragnar is referring to the NMS.AMQP rework proposed earlier on
the dev list.

I believe what was agreed to in principle was to donate the contents of our
github repo:
https://github.com/cjwmorgan-sol-sys/nms-amqp

To replace the contents of the existing NMS.AMQP repo:
https://git-wip-us.apache.org/repos/asf/activemq-nms-amqp.git

Can anyone please provide some guidance on how we should go about doing
this?  Would a reasonable next step be to submit a pull request to the
github mirror (https://github.com/apache/activemq-nms-amqp)?  Or is there a
review and/or vote process that needs to take place first?

Would steps towards an initial release take place after the code is in the
Apache repository? Do we need to integrate with any kind of nightly build
and/or CI infrastructure?

Thanks in advance!

Cheers,
Duane

On Tue, May 15, 2018 at 1:36 PM, Ragnar Paulson 
wrote:

> Greetings,
>
> A while ago (quite a long while ago)  Duane Pauls and Christopher Morgan
> suggested reworking the NMS.AMQP layer for AMQPnetLite.
>
> I have joined them in this effort, today I signed and forwarded a signed
> ICLA to the secretary.
>
> At this point we have a working implementation tested extenstively against
> ActiveMQ and Artemis.  There is a set of tests in the NUNIT framework
> covering the features supported . Documentation is ongoing, testing against
> more brokers, and as always code cleanup details and commenting.
>
> It is a VS2017 project.
>
> So now what are the next steps?  I have heard there may be a continuous
> integration test framework to integrate with.
>
> Regards,
>
> Ragnar Paulson
>

Re: What is the best architecture to set up an activemq cluster to achieve high service and data availability

2018-05-16 Thread maheedhar1010

Thanks MichaelAndrePearce. we will take a look at it



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

Re: [HEADS-UP] 2.5.1 in one week

I just tagged as 2.6.0... It's uploading...

I will cleanup JIRA tonight / tomorrow.. should send the voting thread
soon (tonight or tomorrow)

On Thu, May 10, 2018 at 10:33 AM, Clebert Suconic
 wrote:
> I have been clearing the testsuite. Other guys are working with me on
> that (Francesco, Justin for instance). I'll do as soon as I'm done.
>
> On Thu, May 10, 2018 at 8:24 AM, Christopher Shannon
>  wrote:
>> +1 to make this a 2.6.0 release, there are now over 80 commits and
>> been enough time that I think a 2.6.0 makes more sense
>>
>> On Thu, May 3, 2018 at 12:09 PM, Clebert Suconic
>>  wrote:
>>> Meanwhile please set your fixes as 2.5.1... i will rename it as 2.6.0
>>> before releasing as everything is already filtered there.
>>>
>>> On Thu, May 3, 2018 at 12:04 PM, Clebert Suconic
>>>  wrote:
 From the entire set.. we only have fixes.. and 4 enhancements...
 (previously existent features).

 I would prefer saving 2.6.0 for a more substantial release.. but if
 you guys still prefer calling 2.6.0 I'm fine with that.

 On Thu, May 3, 2018 at 11:02 AM, Robbie Gemmell
  wrote:
> I see there are some updates retargetting JIRA version at 2.5.1 from
> 2.6.0. I think the changes on master are now more suited to the
> release being versioned as 2.6.0. There are plenty of changes in the
> time since 2.5.0 that would have suited 2.5.x releases, but there
> seems to be enough others in there now that might better fit a 2.6.0
> due to adding new functionality etc.
>
> Thoughts?
>
> Robbie
>
> On 26 April 2018 at 22:46, Clebert Suconic  
> wrote:
>> Little snafu today... I'm dealing with a failure in
>> org.apache.activemq.artemis.tests.integration.openwire.amq.RedeliveryPolicyTest.testRedeliveryPolicyPerDestination
>>
>> will send the vote soon.
>>
>> On Wed, Apr 25, 2018 at 9:24 PM, Clebert Suconic
>>  wrote:
>>> I will cut it tomorrow.  I won’t merge anything until it’s out.
>>>
>>> @Commiters please don’t break Anything today :)
>>>
>>> @everyvody if there is anything you want Merged or committed tomorrow 
>>> let me
>>> know.
>>>
>>> On Wed, Apr 25, 2018 at 4:41 PM pwjenkins
>>>  wrote:

 Are you on track to release by the end of April?



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



 --
 Clebert Suconic
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>
>
>
> --
> Clebert Suconic



-- 
Clebert Suconic

[GitHub] activemq-artemis issue #2089: ARTEMIS-1866: Make wait time for reply configu...

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@RaiSaurabh 

> ReplicatedPolicyConfiguration::quorumVoteWait I did not change to final 
as the value will remain the default value until not changed from the 
configuration

That's a choice, but the point is that if you make it modifiable (exposing 
a set on it) you will enable callers to change it anywhere, while making it 
final make clear that it should be set just at construction time and never 
changed at runtime.
It is just a way to document that a value won't be changed anymore.


---

[GitHub] activemq-artemis issue #2089: ARTEMIS-1866: Make wait time for reply configu...

Github user RaiSaurabh commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@franz1981 Thanks for the review further. 
ReplicatedPolicyConfiguration::quorumVoteWait I did not change to final as the 
value will remain the default value until not changed from the configuration. 
If you check the class "FileConfigurationParser" L1322 and L1352 we set the 
updated value if the element is configured in broker.xml else would give the 
default value which we pass. Hope I am making sense.  
I will update the commit message to include more details and then would 
update the PR message to be the same.


---

[GitHub] activemq-artemis pull request #2090: ARTEMIS-1868 Openwire doesn't add deliv...

2018-05-16 Thread gaohoward

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

https://github.com/apache/activemq-artemis/pull/2090#discussion_r188604772
  
--- Diff: 
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQSession.java
 ---
@@ -308,6 +312,8 @@ public int sendMessage(MessageReference reference,
   ServerConsumer consumer,
   int deliveryCount) {
   AMQConsumer theConsumer = (AMQConsumer) consumer.getProtocolData();
+  //clear up possible rolledback ids.
+  rollbackedIds.remove(message.getMessageID());
--- End diff --

Yes I know this adds some costs. But so far I couldn't have a better 
solution.


---

[GitHub] activemq-artemis pull request #2090: ARTEMIS-1868 Openwire doesn't add deliv...

2018-05-16 Thread gaohoward

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

https://github.com/apache/activemq-artemis/pull/2090#discussion_r188604794
  
--- Diff: 
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQSession.java
 ---
@@ -95,6 +97,8 @@
 
private final SimpleString clientId;
 
+   private final Set rollbackedIds = new ConcurrentHashSet<>();
--- End diff --

This I can do. Thanks!


---

[GitHub] activemq-artemis pull request #2091: ARTEMIS-1870:Missing documentation for ...

GitHub user RaiSaurabh opened a pull request:

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

ARTEMIS-1870:Missing documentation for parameter jdbc-journal-sync-period



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

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

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

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


commit 1cd6ed9057f98eb791b87564eeb588eca1d3dc53
Author: saurabhrai 
Date:   2018-05-16T11:55:53Z

ARTEMIS-1870:Missing documentation for new parameter 
jdbc-journal-sync-period added for JDBC Persistence




---

[GitHub] activemq-artemis issue #2089: ARTEMIS-1866: Make wait time for reply configu...

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@RaiSaurabh Good job!! `ReplicatedPolicyConfiguration::quorumVoteWait` is 
still not final and expose setter when not needed


---

[GitHub] activemq-artemis issue #2089: ARTEMIS-1866: Make wait time for reply configu...

Github user RaiSaurabh commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
I have replied and added changes that you suggested and also updated the 
documentation. Could you please review.


---

[GitHub] activemq-artemis pull request #2089: ARTEMIS-1866: Make wait time for reply ...

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

https://github.com/apache/activemq-artemis/pull/2089#discussion_r188589717
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ha/ReplicatedPolicy.java
 ---
@@ -61,6 +61,8 @@
 
private final NetworkHealthCheck networkHealthCheck;
 
+   private int quorumVoteWait = 
ActiveMQDefaultConfiguration.getDefaultQuorumVoteWait();
--- End diff --

This the default value that is configured and it is supposed to change 
hence not kept final.


---

[GitHub] activemq-artemis pull request #2089: ARTEMIS-1866: Make wait time for reply ...

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

https://github.com/apache/activemq-artemis/pull/2089#discussion_r188589506
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/qourum/SharedNothingBackupQuorum.java
 ---
@@ -90,6 +92,7 @@ public SharedNothingBackupQuorum(StorageManager 
storageManager,
   this.networkHealthCheck = networkHealthCheck;
   this.voteRetries = voteRetries;
   this.voteRetryWait = voteRetryWait;
+  this.quorumVoteWait = quorumVoteWait;
--- End diff --

The parameter is already validated when it is picked form the broker .xml.  
You can check class "FileConfigurationParser" L1322 and L1352 for validation of 
number greater than zero.


---

[GitHub] activemq-artemis pull request #2089: ARTEMIS-1866: Make wait time for reply ...

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

https://github.com/apache/activemq-artemis/pull/2089#discussion_r188589019
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/qourum/SharedNothingBackupQuorum.java
 ---
@@ -297,7 +300,7 @@ private boolean isLiveDown() {
 quorumManager.vote(quorumVote);
 
 try {
-   quorumVote.await(LATCH_TIMEOUT, TimeUnit.SECONDS);
+   quorumVote.await(quorumVoteWait, TimeUnit.SECONDS);
 } catch (InterruptedException interruption) {
// No-op. The best the quorum can do now is to return the 
latest number it has
--- End diff --

The await method has already logged on entry. I have added the log in the 
catch block.


---

[GitHub] activemq-artemis pull request #2090: ARTEMIS-1868 Openwire doesn't add deliv...

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

https://github.com/apache/activemq-artemis/pull/2090#discussion_r188532813
  
--- Diff: 
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQSession.java
 ---
@@ -95,6 +97,8 @@
 
private final SimpleString clientId;
 
+   private final Set rollbackedIds = new ConcurrentHashSet<>();
--- End diff --

It could belong to `AMQConsumer` instead of here? That will make it less 
contended, because owned exclusively by the consumer 


---

[GitHub] activemq-artemis pull request #2090: ARTEMIS-1868 Openwire doesn't add deliv...