[GitHub] activemq-artemis pull request: ARTEMIS-19 CLI option for message-l...

2015-06-11 Thread jbertram
GitHub user jbertram opened a pull request:

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

ARTEMIS-19 CLI option for message-load-balancing



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

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

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

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


commit b744edd5878c446878c3540f5592a0dd4bdc1804
Author: jbertram jbert...@apache.org
Date:   2015-06-11T18:08:00Z

ARTEMIS-19 CLI option for message-load-balancing




---
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:

2015-06-11 Thread clebertsuconic
Github user clebertsuconic commented on the pull request:


https://github.com/apache/activemq-artemis/commit/b744edd5878c446878c3540f5592a0dd4bdc1804#commitcomment-11640367
  
You need to validate the types (valid ones). Update the description with 
the ones that are valid. 


---
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: ARTEMIS-91 Separated out interface ...

2015-06-11 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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: ARTEMIS-19 CLI option for message-l...

2015-06-11 Thread jbertram
Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/25#issuecomment-111272599
  
I added some validation, but it's not very graceful.  If the user enters in 
the wrong value it will throw an IllegalArgumentException and the create 
command will terminate.  Obviously I can change this, but I'd like feed-back on 
how.


---
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 pull request: https://issues.apache.org/jira/browse/AMQ-5...

2015-06-11 Thread gaohoward
GitHub user gaohoward opened a pull request:

https://github.com/apache/activemq/pull/112

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

Added synchronization blocks around sentitive code to
prevent concurrent modification of the HashMap.

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

$ git pull https://github.com/gaohoward/activemq master_AMQ-5811

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

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


commit c3ee94a078b3142a490453f9af38287114b25ef0
Author: Howard Gao h...@redhat.com
Date:   2015-06-12T05:22:51Z

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

Added synchronization blocks around sentitive code to
prevent concurrent modification of the HashMap.




---
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: ARTEMIS-127 Fixes compile errors re...

2015-06-11 Thread thiagokronig
GitHub user thiagokronig opened a pull request:

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

ARTEMIS-127 Fixes compile errors reported by Error Prone

This fixes the pom parent version for actimemq5.x-tests project and also 
fix some compile errors.

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

$ git pull https://github.com/thiagokronig/activemq-artemis 
artemis-127-errorprone

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

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


commit 61895223d07ebc58cde504bd57d3b95c0d27b677
Author: Thiago Kronig thiagokro...@gmail.com
Date:   2015-06-10T16:22:08Z

ARTEMIS-127 Fixing activemq-unit-tests pom version

commit aab34e5bd01757c3305691e80d7d3588e5ca0cbe
Author: Thiago Kronig thiagokro...@gmail.com
Date:   2015-06-10T16:23:03Z

ARTEMIS-127 Fixing sync on non-final object for ArtemisBrokerWrapper

commit 64ecb9565dea42c7381e9a70a08339cafff7c960
Author: Thiago Kronig thiagokro...@gmail.com
Date:   2015-06-10T16:24:37Z

ARTEMIS-127 Use L as suffix for long constants

commit ae6a2b87eaa9325d2437db2ccd5152f6db0d2ad3
Author: Thiago Kronig thiagokro...@gmail.com
Date:   2015-06-10T23:37:58Z

ARTEMIS-127 Fix some concurrency idioms for ActimeMQ Tests

commit 4dd54080a1e91463ad4b6693fb1e62ad3a81124a
Author: Thiago Kronig thiagokro...@gmail.com
Date:   2015-06-12T04:27:54Z

ARTEMIS-127 Fix Array.toString(), nonatomic update on volatiles




---
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: Git workflow for committers

2015-06-11 Thread Bruce Snyder
Any branch can be deleted, see 'git branch -d' and 'git branch -D'. Also,
remote branches (like one pushed to the origin) can be removed by doing a
'git push origin :branch_name'.

My only question about the use of git feature branches (which I agree
should definitely be used) is the workflow used to get the commits on a
feature branch back to the master, especially for long-lived branches that
are pushed to the origin like Dan is suggesting. Several experiences have
taught me that allowing the default git merging strategy (i.e.,
fast-forward merges) is a very bad idea because it co-mingles all commits
when a feature branch is merged back to the master branch. In the event
that bad commits need to be plucked out after the merge takes place,
fast-forward merges make this task nearly impossible and can create a very
big mess. I've learned through experience that it is always a better idea
to rebase the master onto the feature branch, resolve all conflicts in
isolation on that feature branch and only then do a non-fast-forward merge
of the feature branch to the master branch. Using non-fast-forward merging
keeps the existence of the feature branch intact (even after it has been
deleted and this is key). Use of non-fast-forward merges makes plucking out
commits from a feature branch much, much easier.

Bruce

On Tue, Jun 9, 2015 at 9:34 PM, Daniel Kulp dk...@apache.org wrote:


  On Jun 9, 2015, at 9:56 PM, Clebert clebert.suco...@gmail.com wrote:
 
  +1. Although Only question I have:
 
  With git it's not really needed to create a branch in the main repo for
 temporary branches.

 Depends on the purpose…..  If I was going to work on a relatively large
 idea/change and want to collaborate with another committer, a branch at
 Apache makes a lot of sense.   For example, I’m thinking about creating one
 to work on the CXF change.  I can keep working on it, all commits would
 still go to the commits@ list so everyone can see what’s going on.
  Others could help out, etc…  Once “done”, it could be merged to master and
 the branch removed.

  But If someone did it thought.  Is it easy to remove a branch with
 Apache git?  I have the impression that you need Infra guys to delete
 branches?
  If only infra structure guys can delete branches I would not encourage
 branches on the main repo.

 The only branch you cannot remove is master.   Anything else is just like
 normal.

 Dan


 
  -- Clebert Suconic typing on the iPhone.
 
  On Jun 9, 2015, at 20:22, Daniel Kulp dk...@apache.org wrote:
 
  I guess if it was up to me to actually write a formal doc describing
 the process it would go something like:
 
 
  ———
 
  ActiveMQ uses a Commit-Then-Review process for getting changes
 contributed to the development branches.   In general, this means the
 ActiveMQ committers are free to directly commit their own work to master
 and push those changes to the canonical repository at Apache.   However,
 the expectation is that the developer has made a good effort to test their
 changes and is reasonably confident that the changes that are being
 committed will not “break the build.”
 
  What does it mean to be reasonably confident?  That may depend on the
 developer.  If the developer has run the same maven commands that the CI
 builds are running, they can likely be reasonably confident.   However, if
 the changes are significant, touches a wide area of code, or even if the
 developer just wants a second opinion, they are encouraged to engage other
 members of the community to obtain an additional review prior to commit.
  This can easily be done via a pull request on github, a patch file
 attached to an email or JIRA, committed to a branch in the Apache git repo,
 etc…  There are a variety of options open to them.Having additional
 eyes looking at significant changes prior to committing to the main
 development branches is definitely encouraged if it helps obtain the
 “reasonable confidence” that the build is not broken and code quality has
 not decreased.  We also have automatic builds setup to test github pull
 requests in advance to help establish a good level of confidence in the
 build.
 
  However, “things happen”.   We’re all human.   In the case where the
 build does break, the expectation is that the developer will make a best
 effort to get the builds fixed in a reasonable amount of time.If it
 cannot be fixed in a reasonable amount of time, the commit can be reverted
 and re-reviewed.
 
  ———
 
  Everyone:  does that about cover it?Did I miss anything?The
 github pull requests and gui tools are definitely a good tool chain in
 certain cases and I would still encourage those folks that find value in
 them to continue using them.   However, they cannot be “required”.
 
 
  Dan
 
 
 
 
 
 
  On Jun 9, 2015, at 7:57 PM, Clebert Suconic 
 clebert.suco...@gmail.com wrote:
 
  +1 to stay with the existing CTR practice that is well established in
 the
  ActiveMQ community. That's why committership 

[GitHub] activemq-artemis pull request: ARTEMIS-91 Separated out interface ...

2015-06-11 Thread jmesnil
Github user jmesnil commented on the pull request:

https://github.com/apache/activemq-artemis/pull/24#issuecomment-111031155
  
looking good, thanks.


---
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.
---


how to find different message states (ideal,running,stop) in active MQ

2015-06-11 Thread mayank_inno
Hello Friends,


I want to find out the timestamp (from consumer) ,when the message start
processing , and when complete their process ..means ideal state time ,
running state time , termination state time just like different states in
Thread..


Thanks
Mayank Agarwal






--
View this message in context: 
http://activemq.2283324.n4.nabble.com/how-to-find-different-message-states-ideal-running-stop-in-active-MQ-tp4697648.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Git workflow for committers

2015-06-11 Thread Clebert
+1000 on rebase before pushing from feature branch 

-- Clebert Suconic typing on the iPhone. 

 On Jun 11, 2015, at 02:08, Bruce Snyder bruce.sny...@gmail.com wrote:
 
 Any branch can be deleted, see 'git branch -d' and 'git branch -D'. Also,
 remote branches (like one pushed to the origin) can be removed by doing a
 'git push origin :branch_name'.
 
 My only question about the use of git feature branches (which I agree
 should definitely be used) is the workflow used to get the commits on a
 feature branch back to the master, especially for long-lived branches that
 are pushed to the origin like Dan is suggesting. Several experiences have
 taught me that allowing the default git merging strategy (i.e.,
 fast-forward merges) is a very bad idea because it co-mingles all commits
 when a feature branch is merged back to the master branch. In the event
 that bad commits need to be plucked out after the merge takes place,
 fast-forward merges make this task nearly impossible and can create a very
 big mess. I've learned through experience that it is always a better idea
 to rebase the master onto the feature branch, resolve all conflicts in
 isolation on that feature branch and only then do a non-fast-forward merge
 of the feature branch to the master branch. Using non-fast-forward merging
 keeps the existence of the feature branch intact (even after it has been
 deleted and this is key). Use of non-fast-forward merges makes plucking out
 commits from a feature branch much, much easier.
 
 Bruce
 
 On Tue, Jun 9, 2015 at 9:34 PM, Daniel Kulp dk...@apache.org wrote:
 
 
 On Jun 9, 2015, at 9:56 PM, Clebert clebert.suco...@gmail.com wrote:
 
 +1. Although Only question I have:
 
 With git it's not really needed to create a branch in the main repo for
 temporary branches.
 
 Depends on the purpose…..  If I was going to work on a relatively large
 idea/change and want to collaborate with another committer, a branch at
 Apache makes a lot of sense.   For example, I’m thinking about creating one
 to work on the CXF change.  I can keep working on it, all commits would
 still go to the commits@ list so everyone can see what’s going on.
 Others could help out, etc…  Once “done”, it could be merged to master and
 the branch removed.
 
 But If someone did it thought.  Is it easy to remove a branch with
 Apache git?  I have the impression that you need Infra guys to delete
 branches?
 If only infra structure guys can delete branches I would not encourage
 branches on the main repo.
 
 The only branch you cannot remove is master.   Anything else is just like
 normal.
 
 Dan
 
 
 
 -- Clebert Suconic typing on the iPhone.
 
 On Jun 9, 2015, at 20:22, Daniel Kulp dk...@apache.org wrote:
 
 I guess if it was up to me to actually write a formal doc describing
 the process it would go something like:
 
 
 ———
 
 ActiveMQ uses a Commit-Then-Review process for getting changes
 contributed to the development branches.   In general, this means the
 ActiveMQ committers are free to directly commit their own work to master
 and push those changes to the canonical repository at Apache.   However,
 the expectation is that the developer has made a good effort to test their
 changes and is reasonably confident that the changes that are being
 committed will not “break the build.”
 
 What does it mean to be reasonably confident?  That may depend on the
 developer.  If the developer has run the same maven commands that the CI
 builds are running, they can likely be reasonably confident.   However, if
 the changes are significant, touches a wide area of code, or even if the
 developer just wants a second opinion, they are encouraged to engage other
 members of the community to obtain an additional review prior to commit.
 This can easily be done via a pull request on github, a patch file
 attached to an email or JIRA, committed to a branch in the Apache git repo,
 etc…  There are a variety of options open to them.Having additional
 eyes looking at significant changes prior to committing to the main
 development branches is definitely encouraged if it helps obtain the
 “reasonable confidence” that the build is not broken and code quality has
 not decreased.  We also have automatic builds setup to test github pull
 requests in advance to help establish a good level of confidence in the
 build.
 
 However, “things happen”.   We’re all human.   In the case where the
 build does break, the expectation is that the developer will make a best
 effort to get the builds fixed in a reasonable amount of time.If it
 cannot be fixed in a reasonable amount of time, the commit can be reverted
 and re-reviewed.
 
 ———
 
 Everyone:  does that about cover it?Did I miss anything?The
 github pull requests and gui tools are definitely a good tool chain in
 certain cases and I would still encourage those folks that find value in
 them to continue using them.   However, they cannot be “required”.
 
 
 Dan
 
 
 
 
 
 
 On Jun 9, 2015, at 

[GitHub] activemq-artemis pull request: ARTEMIS-19 + ARTEMIS-109

2015-06-11 Thread clebertsuconic
Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/25#issuecomment-111321276
  
I will merge it for now.. there's another task to make better errors.. we 
can do it as part of that 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 pull request: ARTEMIS-19 + ARTEMIS-109

2015-06-11 Thread clebertsuconic
Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/25#issuecomment-111330013
  
@jbertram  I made one small change to this at 
145fc7f82c1c5513403df4af90e1e2dbe24586a0

the CLI framework can handle the conversion already.


Going beyond this we need to treat exception per 
https://issues.apache.org/jira/browse/ARTEMIS-116

Also, whenever you have a chance please close these JIRAs?


---
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: ARTEMIS-19 + ARTEMIS-109

2015-06-11 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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 pull request: https://issues.apache.org/jira/browse/AMQ-5...

2015-06-11 Thread cshannon
GitHub user cshannon opened a pull request:

https://github.com/apache/activemq/pull/111

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

Modifying start up scripts to consistently use the same property names

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

$ git pull https://github.com/cshannon/activemq AMQ-5836

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

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


commit 85ad4199a247ee375d30d26d02fbc044cbc38a83
Author: Christopher L. Shannon christopher.l.shan...@gmail.com
Date:   2015-06-12T01:35:33Z

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

Modifying start up scripts to consistently use the same property names




---
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.
---