[GitHub] activemq-artemis issue #1096: ARTEMIS-1041 Apply absolute expiration time to...

[tabish121]

Github user tabish121 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1096
  
That just means you have to start on the next one


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1096: ARTEMIS-1041 Apply absolute expiration time to...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1096
  
@tabish121  best working day ever. I procrastinated an afternoon trying to 
figure out the QA test and you fixed it 👍 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1096: ARTEMIS-1041 Apply absolute expiration ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1096: ARTEMIS-1041 Apply absolute expiration ...

[tabish121]

GitHub user tabish121 opened a pull request:

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

ARTEMIS-1041 Apply absolute expiration time to message

Use the Absolute Expiration Time from the message properties and
override any value set in TTL if anything set there.

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

$ git pull https://github.com/tabish121/activemq-artemis ARTEMIS-1041

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

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


commit 5d434b1fd6c2a6c8a3e4f939aede4486a5060481
Author: Timothy Bish 
Date:   2017-03-15T20:25:40Z

ARTEMIS-1041 Apply absolute expiration time to message

Use the Absolute Expiration Time from the message properties and
override any value set in TTL if anything set there.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1094: ARTEMIS-1038 Make usage of Delivery.ava...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Single version docs on Artemis

[Andy Taylor]

Personally, I would prefer a separate repo for the docs, its fine to have
versions linked to a release but then they are set in stone. Docs are
usually the last thing to get written and sometimes rushed or maybe not
even in time for a release. If they were in a separate repo you could still
spend time improving them as a separate effort, adding missing info, fixing
mistakes etc. we could still ship them with a release if we wanted but also
allow for further updates after then. We could also have 2 streams in 1 for
1.5 and 1 for 2.0.

Andy

On 15 March 2017 at 13:56, Clebert Suconic 
wrote:

> On Wed, Mar 15, 2017 at 6:57 AM, Martyn Taylor  wrote:
> > I'd prefer to keep the latest versions of docs for each minor release.
> I'd
> > squash all the 1.5.x into just 1.5, but keep 1.0, 1.1 etc...  The 1.5
> docs
> > may not be applicable to 1.4 due to the introduction of new features.
> 1.0
> > for example, is very different from 1.5, but we I feel we should still
> > provide docs for those users who have not been able to upgrade.
>
> Users can refer to the docs on github or on the downloaded package
> also. We could even add a note to where to relate the docs if you're
> on a older version.
>
>
> 2 years from now... 2.1, 2.2, 2.3... .the list will only grow...
>
>
> We're even encouraged to archive older downloads from apache
> guidelines.. I believe Tim Bish did some cleanup on ActiveMQ and
> Artemis last year for that reason.
>
>
> >
> > On a related note, (I can start a separate DISCUSS thread on this if
> people
> > prefer).
> > I'd like to also suggest that we stop distributing the documentation as
> > part of the release distribution and instead just provide links to the
> > latest versions.  Having the docs released as part of the binary and
> source
> > distribution, means that we need to do a full Artemis release just to get
> > doc changes out.  Instead I'd like to see docs either on their own
> release
> > cycle or just built periodically, housed somewhere and linked to from the
> > distribution.  Thoughts?
>
> I would keep the docs on the release the way it is, for the reason I
> mentioned before.. we wouldn't keep 1.0, 1.1.  1.N, 2.N on the
> website.
>
> But then minor updates could go to the website right away without
> requiring a release just for that.
>
> We could even add a link for a more updated documentation visit us @
> .. (Link goes here).
>

[GitHub] activemq-artemis issue #1093: ARTEMIS-994 Support Netty Native Epoll on Linu...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1093
  
@clebertsuconic sounds good. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Rework NMS.AMQP

[Timothy Bish]

On 03/15/2017 11:31 AM, cmorgan wrote:

Thanks Tim, I will transition my development work to the Apache repo. The
project is currently unstable so, once it has become (at least more) stable
I will begin the transition.

Would a pull request through the github mirror be sufficient?


Once you've sorted you CCLA / ICLA issues out I'd suggest creating a new 
NMS JIRA issue covering the task, possibly as one
root issue with subtasks for various work items like cleaning out the 
current code tree, updating the build system etc until you get to the 
finished product.  Subtasks with targeted PRs against the github mirror 
would make the review process easier than one gigantic PR.


The Artemis team has a nice hacking guide that describes the general 
Github work-flow with examples of the what the commit message should 
look like etc.  Always include the JIRA issue in the commit and the PR 
for instance so that the tooling can link back the details and 
discussion to the associated JIRA issue for later reference.


The Artemis guide is here: 
http://activemq.apache.org/artemis/docs/1.5.3/hacking-guide/index.html





tabish...@gmail.com wrote

I created a branch for the previous work and named it deprecated-impl
(for want of a better name) and pushed it upstream.  Should be clear now
to start on any new development of this client as folks see fit.

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

Chris Morgan



-
Chris Morgan
--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Rework-NMS-AMQP-tp4721986p4723793.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.




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

Re: [DISCUSS] Rework NMS.AMQP

[cmorgan]

Thanks Tim, I will transition my development work to the Apache repo. The
project is currently unstable so, once it has become (at least more) stable
I will begin the transition.

Would a pull request through the github mirror be sufficient? 


tabish...@gmail.com wrote
> I created a branch for the previous work and named it deprecated-impl 
> (for want of a better name) and pushed it upstream.  Should be clear now 
> to start on any new development of this client as folks see fit.
> 
> -- 
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/

Chris Morgan



-
Chris Morgan
--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Rework-NMS-AMQP-tp4721986p4723793.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[GitHub] activemq-artemis issue #1093: ARTEMIS-994 Support Netty Native Epoll on Linu...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1093
  
@michaelandrepearce I will add a new generic parameter, and deprecate the 
old one.

Will do that on a separate commit. I just wanted to know if you had any 
reason.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #1093: ARTEMIS-994 Support Netty Native Epoll on Linu...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1093
  
@clebertsuconic I though about this but annoyingly theyre named nioBlah as 
such just using that would be not directly indicate you're affecting epoll. 
Like wise if we were to strip the nio part then they would be generic but would 
break any compatibility with existing clients as they'd have to change their 
properties if used. 

This is why I introduce the extra duplicate props. If you think renaming 
the existing properties to generic in nature I can do this but as noted 
wouldn't be back compatible.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Single version docs on Artemis

[Clebert Suconic]

On Wed, Mar 15, 2017 at 6:57 AM, Martyn Taylor  wrote:
> I'd prefer to keep the latest versions of docs for each minor release.  I'd
> squash all the 1.5.x into just 1.5, but keep 1.0, 1.1 etc...  The 1.5 docs
> may not be applicable to 1.4 due to the introduction of new features.  1.0
> for example, is very different from 1.5, but we I feel we should still
> provide docs for those users who have not been able to upgrade.

Users can refer to the docs on github or on the downloaded package
also. We could even add a note to where to relate the docs if you're
on a older version.


2 years from now... 2.1, 2.2, 2.3... .the list will only grow...


We're even encouraged to archive older downloads from apache
guidelines.. I believe Tim Bish did some cleanup on ActiveMQ and
Artemis last year for that reason.


>
> On a related note, (I can start a separate DISCUSS thread on this if people
> prefer).
> I'd like to also suggest that we stop distributing the documentation as
> part of the release distribution and instead just provide links to the
> latest versions.  Having the docs released as part of the binary and source
> distribution, means that we need to do a full Artemis release just to get
> doc changes out.  Instead I'd like to see docs either on their own release
> cycle or just built periodically, housed somewhere and linked to from the
> distribution.  Thoughts?

I would keep the docs on the release the way it is, for the reason I
mentioned before.. we wouldn't keep 1.0, 1.1.  1.N, 2.N on the
website.

But then minor updates could go to the website right away without
requiring a release just for that.

We could even add a link for a more updated documentation visit us @
.. (Link goes here).

[GitHub] activemq-artemis issue #1093: ARTEMIS-994 Support Netty Native Epoll on Linu...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1093
  
@michaelandrepearce I don't think you really need three parameters for 
this... just one would do...

- useEpoll...


the other two you introduced could just use the same parameter, being the 
same semantic.. being just epoll.


That way you would configure to use epoll or not with a single switch. If 
you need to configure different settings.. than you can just update the 
values.. it gets easier on users IMHO.


WDYT?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Single version docs on Artemis

[Robbie Gemmell]

What we do for Qpid is to have a central documentation/download etc
page that links to the latest release artifacts and documentation for
each component, but then also have specific pages for each component
release that includes the artifacts and docs for each specific
release. Those are also referenced from a page of current and past
releases, which is in turn referenced elsewhere on the site. This way
there is a simple area with the current docs for the current releases,
but the site still has specific pages for earlier releases that
includes their precise docs should anyone need them. We clear out the
old release content over time, e.g 2-3 years, to keep the size of the
site in check, as the docs are still available in the actual releases
themselves, which continue to be available from the dist archive,
which the site again references.

In the case where we want to update the docs of a prior release, we
can just do that on the site if so desired, though this is very rare.
The site docs for each component+version are processed from the
original release source tag when first published, and its source
becomes independant from that point unless specifically reprocessed
over the top of. Some components do link to their docs on the site,
allowing site updates to be picked up, though they are still included
in at least source form in the original release of the component.

On 15 March 2017 at 10:57, Martyn Taylor  wrote:
> I'd prefer to keep the latest versions of docs for each minor release.  I'd
> squash all the 1.5.x into just 1.5, but keep 1.0, 1.1 etc...  The 1.5 docs
> may not be applicable to 1.4 due to the introduction of new features.  1.0
> for example, is very different from 1.5, but we I feel we should still
> provide docs for those users who have not been able to upgrade.
>
> On a related note, (I can start a separate DISCUSS thread on this if people
> prefer).
>
> I'd like to also suggest that we stop distributing the documentation as
> part of the release distribution and instead just provide links to the
> latest versions.  Having the docs released as part of the binary and source
> distribution, means that we need to do a full Artemis release just to get
> doc changes out.  Instead I'd like to see docs either on their own release
> cycle or just built periodically, housed somewhere and linked to from the
> distribution.  Thoughts?
>
> Regards
> Martyn
> On Mon, Mar 13, 2017 at 9:11 PM, Clebert Suconic 
> wrote:
>
>> Let's make the links 2.x and 1.x.  Immutable links makes it easier on
>> google?
>> On Mon, Mar 13, 2017 at 4:47 PM Timothy Bish  wrote:
>>
>> > On 03/13/2017 04:44 PM, Clebert Suconic wrote:
>> > > Right now we have 10. And going up.
>> > >
>> > > 1.0, 1.1,   1.5.0 1.5.11.5.4. 2.0
>> >
>> > I think John is saying the same thing I said earlier, only keep 1.5.4
>> > and 2.0.0 as those are the latest supported releases, when 1.5.5 ships
>> > then drop 1.5.4 ...
>> >
>> > >
>> > > On Mon, Mar 13, 2017 at 4:37 PM Timothy Bish 
>> > wrote:
>> > >
>> > >> On 03/13/2017 04:07 PM, Clebert Suconic wrote:
>> > >>> Sure.   Latest 1.x and latest 2.x.
>> > >>>
>> > >>>
>> > >>>
>> > >>> Just that it seems too much now.
>> > >> Isn't that just two instances?  That doesn't seem like to much.
>> > >>
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Mon, Mar 13, 2017 at 1:42 PM Jiri Danek 
>> wrote:
>> > >>>
>> >  On Mon, Mar 13, 2017 at 6:27 PM, Clebert Suconic <
>> >  clebert.suco...@gmail.com>
>> >  wrote:
>> > 
>> > > I was wondering if we could / should update the docs page to only
>> > > include the latest version (that is 2.0.0)... The docs are still
>> > > maintained at the git, so you can always refer to the doc of the
>> > > version you're using when you download.. or you can use links from
>> > > github.
>> > >
>> >  It seems strange to maintain the 1.x release stream and not have
>> >  documentation for it on the site. There should be at least the
>> latest
>> > >> 1,x
>> >  and the latest 2.0 version.
>> > 
>> >  The projects whose documentation I often browse online all have
>> > previous
>> >  doc versions on the site, be it https://www.postgresql.org/docs/,
>> > >> Python
>> >  or
>> >  readthedocs.io hosted sites like http://docs.pachyderm.io/en/
>> stable/
>> > >> (see
>> >  the version picker at the bottom left).
>> > 
>> >  readthedocs.io sites also have a noticebar that alerts users that
>> > they
>> > >> are
>> >  browsing documentation for older release; I once raised this as
>> > feature
>> >  request https://issues.apache.org/jira/browse/ARTEMIS-615
>> > 
>> > 
>> > > That would also make it easier for web robots (google, etc)  to
>> index
>> > >> it.
>> >  http://www.example.com/canonical-version-of-page/;
>> >  rel="canonical" />
>> > 
>> >  in the 

Re: [DISCUSS] Single version docs on Artemis

[Martyn Taylor]

I'd prefer to keep the latest versions of docs for each minor release.  I'd
squash all the 1.5.x into just 1.5, but keep 1.0, 1.1 etc...  The 1.5 docs
may not be applicable to 1.4 due to the introduction of new features.  1.0
for example, is very different from 1.5, but we I feel we should still
provide docs for those users who have not been able to upgrade.

On a related note, (I can start a separate DISCUSS thread on this if people
prefer).

I'd like to also suggest that we stop distributing the documentation as
part of the release distribution and instead just provide links to the
latest versions.  Having the docs released as part of the binary and source
distribution, means that we need to do a full Artemis release just to get
doc changes out.  Instead I'd like to see docs either on their own release
cycle or just built periodically, housed somewhere and linked to from the
distribution.  Thoughts?

Regards
Martyn
On Mon, Mar 13, 2017 at 9:11 PM, Clebert Suconic 
wrote:

> Let's make the links 2.x and 1.x.  Immutable links makes it easier on
> google?
> On Mon, Mar 13, 2017 at 4:47 PM Timothy Bish  wrote:
>
> > On 03/13/2017 04:44 PM, Clebert Suconic wrote:
> > > Right now we have 10. And going up.
> > >
> > > 1.0, 1.1,   1.5.0 1.5.11.5.4. 2.0
> >
> > I think John is saying the same thing I said earlier, only keep 1.5.4
> > and 2.0.0 as those are the latest supported releases, when 1.5.5 ships
> > then drop 1.5.4 ...
> >
> > >
> > > On Mon, Mar 13, 2017 at 4:37 PM Timothy Bish 
> > wrote:
> > >
> > >> On 03/13/2017 04:07 PM, Clebert Suconic wrote:
> > >>> Sure.   Latest 1.x and latest 2.x.
> > >>>
> > >>>
> > >>>
> > >>> Just that it seems too much now.
> > >> Isn't that just two instances?  That doesn't seem like to much.
> > >>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Mar 13, 2017 at 1:42 PM Jiri Danek 
> wrote:
> > >>>
> >  On Mon, Mar 13, 2017 at 6:27 PM, Clebert Suconic <
> >  clebert.suco...@gmail.com>
> >  wrote:
> > 
> > > I was wondering if we could / should update the docs page to only
> > > include the latest version (that is 2.0.0)... The docs are still
> > > maintained at the git, so you can always refer to the doc of the
> > > version you're using when you download.. or you can use links from
> > > github.
> > >
> >  It seems strange to maintain the 1.x release stream and not have
> >  documentation for it on the site. There should be at least the
> latest
> > >> 1,x
> >  and the latest 2.0 version.
> > 
> >  The projects whose documentation I often browse online all have
> > previous
> >  doc versions on the site, be it https://www.postgresql.org/docs/,
> > >> Python
> >  or
> >  readthedocs.io hosted sites like http://docs.pachyderm.io/en/
> stable/
> > >> (see
> >  the version picker at the bottom left).
> > 
> >  readthedocs.io sites also have a noticebar that alerts users that
> > they
> > >> are
> >  browsing documentation for older release; I once raised this as
> > feature
> >  request https://issues.apache.org/jira/browse/ARTEMIS-615
> > 
> > 
> > > That would also make it easier for web robots (google, etc)  to
> index
> > >> it.
> >  http://www.example.com/canonical-version-of-page/;
> >  rel="canonical" />
> > 
> >  in the HTML head section should take care of that. This is what
> >  readthedocs.io does.
> >  --
> >  Jiří Daněk
> >  Messaging QA
> > 
> > >>
> > >> --
> > >> Tim Bish
> > >> twitter: @tabish121
> > >> blog: http://timbish.blogspot.com/
> > >>
> > >> --
> > > Clebert Suconic
> > >
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> > --
> Clebert Suconic
>

[GitHub] activemq-artemis issue #1093: ARTEMIS-994 Support Netty Native Epoll on Linu...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1093
  
@clebertsuconic I have just now rebased and squashed, hope this is what you 
were wanting me to do.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---