[jira] [Commented] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414015#comment-17414015
]
Michael Andre Pearce commented on AMQNET-727:
-
[~andredem] - please feel free to contribute a PR to fix.
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (AMQNET-720) Maintaining Balance in a Technological World
[ https://issues.apache.org/jira/browse/AMQNET-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-720: > Maintaining Balance in a Technological World > > > Key: AMQNET-720 > URL: https://issues.apache.org/jira/browse/AMQNET-720 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Nerea Kaufman >Priority: Major > > In the modern age of texts, tweets, and status updates, it is of utmost > importance that parents maintain open lines of face-to-face, soul-to-soul > communication with their children. This does not mean resisting a highly > technological world that is not going away, but rather continually exploring > new ways to connect with one another both on and beyond the keyboard. The new > technology in and of itself is not detrimental to children and can be quite > useful to them in many ways, but it must be coupled with daily opportunities > for personal reflection, creative inspiration, and heart connection with > others. It becomes the parents' role to both monitor technological use as > their children's sole means of communication and to provide the space and > encouragement for life-affirming communication and choices. > Today's children often become immersed in a world of technology and > friendships that may seem quite foreign to parents. The more attuned parents > are to their children's interests other than technology, the better able they > are to utilize those interests as opportunities for expanded connection. > Parents can view all interests as possible pathways to enhance real life > interactions. Parents must observe closely what truly brings their children > joy, where they are most authentic, and what makes their eyes sparkle. To > light the path of infusing deeper meaning into everyday life, parents must > continually assess whether they are offering a true understanding of core > concepts like authenticity, self-love, connectedness, gratitude and presence > in tandem with their children's inevitable foray into a fast-paced and > ever-changing technological world. Parents must not only teach these concepts > but also model ways for their children to integrate them into life > experiences and relationships. > The invitation for all parents is to actively participate in as many areas of > their children's lives as possible without decreasing their natural move > towards independence. Children's passions when viewed from an expanded > perspective offer rich material and opportunity to connect with them in deep > and joyous ways. Songs, movies, and all veins of creative expression (even > technology) provide optimal entry points into daily conversation and in-depth > discussion. Parents can utilize everyday life to dissect and review the core > concepts mentioned above to expand perspective and enhance the parent/child > bond. The space and opportunity to discuss the touchstones of the day can be > created through a weekly family discussion, a nightly chat at bedtime, the > family dinner, or time spent together in the car with technology off. Parents > must be continually on the lookout for a bridge into their children's world, > while at the same time enforce time-outs from computerized communication. > Due to the fact that the new technology is here to stay, to resist it > outright will create a backlash for parents and children alike. Instead, the > best strategy is to discuss often and enforce expectations regarding > appropriate use. Parents must explain to their children why balance in this > area is vital to their overall well-being. The capacity to be inspired to > create in any venue requires downtime, reflection, openness, and connection > to the deeper space within. It is important for children to understand that > there is a place for multi-tasking and technological communication, but it is > the relationship with their own interior and life itself that ignites their > highest potential. > As parents give their children permission to be authentic in their choices, > they must also offer them the parental insight that there are multiple angles > to every choice. Parents can encourage transparency and honesty by creating a > family structure that helps children monitor their choices-such as computer > use on the first floor only and no hand-held devices allowed during meal > times, family outings, or after 8pm. Parents should not be afraid to expect > and enforce accountability, while at the same time remain open to the child's > new world. It is imperative that parents take the time to teach children that > current choices affect future reality. In other words, parents should assist > them in coming to understand that they are the source, not the effect-joy > begets more joy, inspiration begets
[jira] [Deleted] (AMQNET-726) abc
[ https://issues.apache.org/jira/browse/AMQNET-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-726: > abc > --- > > Key: AMQNET-726 > URL: https://issues.apache.org/jira/browse/AMQNET-726 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: clifford9988 >Priority: Critical > > in which To enter the business hard at all as there are very few hindrances > to section, anyway somebody who is intrigued requirements to consider of the > significant expenses in setting up an auto vendor. All organizations in this > market are for the most part dependent on item separation to contend and > keeping in mind that costs are not "tacky", evaluating rivalry is set up by > the market. https://junkcaryard.ca/scrap-car-removal-niagara-falls/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377910#comment-17377910 ] Michael Andre Pearce commented on AMQ-7514: --- [~ehossack] i appreciate that. This said just because something works somewhere else, within a given context doesn't mean it automatically works else where. Like wise i really would like to avoid renaming the meanings of everything. The word "active" has existing terminology and meaning, along side what master / slave means especially in Artemis. And want to avoid overusing that word to mean different and new things. I would really like to see/hear alternative proposals from yourselves, rather than simply pushing only the nomenclature you use at AWS. As i keep calling out, there is many alternatives and well adopted alternatives to Master / Slave terminology, lets explore and propose some alternatives, that do not clash with existing terminology and naming used / historic ones, to avoid confusions. I'm open to alternatives, im just a bit against s/master/active/g in our code bases, due to existing meanings and historic usage within the project. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:16 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis. was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:15 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes Terminology Alignment is important! > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:14 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes Terminology Alignment is important! was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:13 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce commented on AMQ-7514: --- But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:05 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:04 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{{
}}
{{}}
{{}}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:03 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{{
}}
{{}}
{{}}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:00 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:58 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:57 AM: The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. Further to this point, even now today still theres code in classic where we have "Passive Slave" where passive is the state. was (Author: michael.andre.pearce): The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861 ] Michael Andre Pearce commented on AMQ-7514: --- The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:53 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, and becomes and Active Replica but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader /
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:49 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:47 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:45 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:43 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:43 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:42 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:41 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:39 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:38 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 >
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:34 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:33 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:30 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:28 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:28 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:26 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about Active MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:25 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about Active MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] We actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ >
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce commented on AMQ-7514: --- I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] We actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQNET-665) Compression Compatibility with 1.7.x
Michael Andre Pearce created AMQNET-665: --- Summary: Compression Compatibility with 1.7.x Key: AMQNET-665 URL: https://issues.apache.org/jira/browse/AMQNET-665 Project: ActiveMQ .Net Issue Type: Bug Reporter: Michael Andre Pearce In 1.8.0 Ionic ZLib was removed as is no longer supported, but at the time no other suitable library was found. But this breaks compatibility with 1.7.x and also cross language compression e.g. to java. [[AMQNET-565] - .net standard conversion, project reorganization by killnine · Pull Request #9 · apache/activemq-nms-openwire (github.com)|https://github.com/apache/activemq-nms-openwire/pull/9] A new library to support the compression should be found, and the default compression updated. It seems SharpZipLib maybe able to fix this, at the need to update min framework to 4.5 [Fixed #2255 - Hacked in the use of a support ZLib decompression libra… · MassTransit/MassTransit@4b6bb6e (github.com)|https://github.com/MassTransit/MassTransit/commit/4b6bb6ea639fec5d39e6dbd2226fc86243281cb3] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Deleted] (AMQNET-662) One Of The Most Important Factors - Best Female Characters
[ https://issues.apache.org/jira/browse/AMQNET-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-662: > One Of The Most Important Factors - Best Female Characters > -- > > Key: AMQNET-662 > URL: https://issues.apache.org/jira/browse/AMQNET-662 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: leolafox >Priority: Major > > Anime females are a happening by themselves -- that they represent the best > female, and thus are far attractive compared to women in true to living. They > offer you the best of the two worlds: blessed with all terrific appearances > and an amazing character. Who wouldn't find an anime girl's curvy hour glass > figure, enormous breasts, and a refined feminine personality attractive? > Why would you discover them hot and cute Girl Anime? > In a ideal universe, most of girls would be cute and hot using endearing > personalities.This is exactly where anime girls arrive in; they have been > designed to become perfect. Like many kinds of cartoon, > [Anime|https://animenami.com/] was created to recreate its viewers in a > different globe. What is beautiful is subjective, so therefore there are wide > range of women to satisfy the interests. Just like large-breasted ladies, or > what about the tiny sister type of girl? What about tsundere ladies, or women > that start outside me an and eventually warm to you? Have a fetish to get > ponytails? There really are a huge selection of arcade girls to get virtually > any person. > An arcade lady personality can be considered more because of her subjective > attractiveness one of her audience; this allure would create one want her -- > desire to hang with her, and need to be her boyfriend, desire to wed her, and > even want to become her dad. If she happens to get psychological, you want to > be along with her to console her, and telling her it's all right, we are > there for her. > Anime girls enable us to experience a fantasy like no other. Visual books > (VNs) are a favorite type of game in Japan, normally featuring enticing > [อนิเมะ|https://animenami.com/] and a single male protagonist intending to > acquire one of those female's hearts. All these girls are non-judgmental; > they don't care exactly what you appear to be or how you act, even if you are > extremely bashful. A woman does not care if you're alpha or beta male, and > sometimes even an saline man. All she would enjoy is to present you, and even > become her boyfriend while in the long run. > Rebuttal > Considering anime chicks are adorable and hot is just a harmless fantasy -- > this sort of dreams offer those who have trouble accomplishing exactly the > things they really want in life. Even if you cannot be physically there for > these, the vicarious experience can make it almost seem as if it have been > thanks to moe. It isn't objectifying the female gender, as anime chicks are > complex as though they truly are actual women with characters and emotions. > Picking a Thai dubbing Anime picture or series at AnimeNami, It's the best > choice for you as you watch all the series and movies without any price. > Enjoy the whole afternoon to see some other music films or string without any > prices. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288791#comment-17288791
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:35 AM:
-
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java]
attached to start up an actual port, instead of invm only, and then adjusted
the test cases to use the activemq 5.x jms client, and ran the tests, and they
pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is
>something [~cshannon] added to fix a filter issue. in ARTEMIS-2531
git hash:
ad0581bf76043322934290d489f3f4489ac2536b
was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java]
attached to start up an actual port, instead of invm only, and then adjusted
the test cases to use the activemq 5.x jms client, and ran the tests, and they
pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is
>something [~cshannon] added to fix a filter issue.
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288791#comment-17288791
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:31 AM:
-
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java]
attached to start up an actual port, instead of invm only, and then adjusted
the test cases to use the activemq 5.x jms client, and ran the tests, and they
pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is
>something [~cshannon] added to fix a filter issue.
was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java]
attached to start up an actual port, instead of invm only, and then adjusted
the test cases to use the activemq 5.x jms client, and ran the tests, and they
pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288791#comment-17288791
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:26 AM:
-
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java]
attached to start up an actual port, instead of invm only, and then adjusted
the test cases to use the activemq 5.x jms client, and ran the tests, and they
pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and
then adjusted the test cases to use the activemq 5.x jms client, and ran the
tests, and they pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288791#comment-17288791
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:25 AM:
-
[~jbertram] I modified [^FederatedQueueTest.java]and
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and
then adjusted the test cases to use the activemq 5.x jms client, and ran the
tests, and they pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within junit to demonstrate the issue, then we can look at more.
was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and
then adjusted the test cases to use the activemq 5.x jms client, and ran the
tests, and they pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within unit, then we can look at more.
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288791#comment-17288791
]
Michael Andre Pearce commented on ARTEMIS-2802:
---
[~jbertram] I modified [^FederatedQueueTest.java]and
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and
then adjusted the test cases to use the activemq 5.x jms client, and ran the
tests, and they pass. So currently im unsure of the issue, it be great if
FederatedQueueTest.java can be extended with a failure test case that will run
within unit, then we can look at more.
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce updated ARTEMIS-2802:
--
Attachment: FederatedTestBase.java
FederatedQueueTest.java
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288121#comment-17288121
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/22/21, 1:33 AM:
-
[~jbertram] The above description doesnt really tell me how to re-create the
users issue apart from its something with openwire. Do they have unit or
integration test to re-create? Im not running federation with brokers that have
OpenWire enabled, only where CORE is being used, so a test case would need to
be supplied that can be run in the test suites
was (Author: michael.andre.pearce):
[~jbertram] The above description doesnt really tell me how to re-create the
users issue apart from its something with openwire. Do they have unit or
integration test to re-create? Im not running federation with brokers that have
OpenWire enabled, so a test case would need to be supplied that can be run in
the test suites
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288121#comment-17288121
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/22/21, 1:32 AM:
-
[~jbertram] The above description doesnt really tell me how to re-create the
users issue apart from its something with openwire. Do they have unit or
integration test to re-create? Im not running federation with brokers that have
OpenWire enabled, so a test case would need to be supplied that can be run in
the test suites
was (Author: michael.andre.pearce):
[~jbertram] The above description doesnt really tell me how to re-create the
users issue. Do they have unit or integration test to re-create? Im not running
federation with brokers that have OpenWire enabled, so a test case would need
to be supplied that can be run in the test suites
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288121#comment-17288121
]
Michael Andre Pearce commented on ARTEMIS-2802:
---
The above description doesnt really tell me how to re-create the users issue.
Do they have unit or integration test to re-create? Im not running federation
with brokers that have OpenWire enabled, so a test case would need to be
supplied that can be run in the test suites
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288121#comment-17288121
]
Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/22/21, 1:31 AM:
-
[~jbertram] The above description doesnt really tell me how to re-create the
users issue. Do they have unit or integration test to re-create? Im not running
federation with brokers that have OpenWire enabled, so a test case would need
to be supplied that can be run in the test suites
was (Author: michael.andre.pearce):
The above description doesnt really tell me how to re-create the users issue.
Do they have unit or integration test to re-create? Im not running federation
with brokers that have OpenWire enabled, so a test case would need to be
supplied that can be run in the test suites
> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
>
> Reproducible by switching from:
>
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>
> and adding dependency:
> {code:java}
>
> org.apache.activemq
> activemq-client
> ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter:
> hyphenated_props:federation-name IS NOT NULL}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-637: Fix Version/s: (was: AMQP-2.0.0) > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 9h > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-637: Fix Version/s: AMQP-2.0.0 > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0, AMQP-2.0.0 > > Time Spent: 9h > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-637: Fix Version/s: (was: 2.0.0) API-2.0.0 > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 9h > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-565. --- > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ, NMS, OpenWire >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0, OpenWire-1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved AMQNET-565. - Resolution: Fixed > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ, NMS, OpenWire >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0, OpenWire-1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-565: Fix Version/s: OpenWire-1.8.0 > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ, NMS, OpenWire >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0, OpenWire-1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-565: Component/s: NMS OpenWire > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ, NMS, OpenWire >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce reopened AMQNET-565: - > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-490) Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ (Jboss 6.4.2 GA)
[
https://issues.apache.org/jira/browse/AMQNET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce updated AMQNET-490:
Fix Version/s: (was: 1.8.0)
> Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ
> (Jboss 6.4.2 GA)
> -
>
> Key: AMQNET-490
> URL: https://issues.apache.org/jira/browse/AMQNET-490
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: Stomp
>Affects Versions: 1.5.4
>Reporter: Harley Blumenfeld
>Priority: Major
>
> Maybe I am doing something dumb, but using a simple example I cannot seem to
> get a topic subscription working using the Apache.NMS.Stomp version 1.5.4
> (http://activemq.apache.org/nms/apachenmsstomp-v154.html).
> I am compiling the Stomp source code and project under .Net 4.0. I have
> created a console application in the Apache.NMS.Stomp solution. My program
> fails when it attempts to create a subscription to the topic. The same
> example works fine with the 1.5.3 version of the DLL so this seems like it
> could be a bug.
> Here is the result of my simple program:
> About to connect to stomp:tcp://myjboss:61613
> Using destination: topic://jms.topic.test.topic
> Connection Error: : Error creating subscription
> IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
> Connection Error:
> Error: : Error creating subscription
> IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
> Error: at Apache.NMS.Stomp.Connection.SyncRequest(Command command, TimeSpan
> requestTimeout) in
> C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
> 525
>at Apache.NMS.Stomp.Connection.SyncRequest(Command command) in
> C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
> 505
>at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination,
> String selector, Boolean noLocal) in
> C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
> 425
>at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination) in
> C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
> 379
>at TopicSubscriberTest.Program.Main(String[] args) in
> C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\TopicSubscribeTest\Program.cs:line
> 31
> Here is the code:
> class Program
> {
> private static void Main(string[] args)
> {
> try
> {
> var connecturi = new Uri("stomp:tcp://myjboss:61613");
> Console.WriteLine("About to connect to " + connecturi);
> IConnectionFactory factory = new
> NMSConnectionFactory(connecturi);
> using (IConnection connection =
> factory.CreateConnection("testuser", "test"))
> {
> connection.ExceptionListener += new
> ExceptionListener(OnConnectionException);
> connection.Start();
> using (ISession session =
> connection.CreateSession())
> {
> connection.Start();
>
> IDestination destination =
> SessionUtil.GetDestination(session,"topic://jms.topic.test.topic");
> Console.WriteLine("Using destination: "
> + destination);
> using (IMessageConsumer consumer =
> session.CreateConsumer(destination))
> {
>
> consumer.Listener += OnMessage;
> while (true)
> {
> Thread.Sleep(5000);
> Console.WriteLine(".");
> }
> }
> }
> }
> }
> catch (Exception e)
> {
> Console.WriteLine("Error:" + e.Message);
> Console.WriteLine("Error:" + e.StackTrace);
> Console.ReadLine();
> }
> }
> private static void OnConnectionException(Exception e)
> {
> Console.WriteLine("Connection Error:" + e.Message);
> Console.WriteLine("Connection Error:" + e.StackTrace);
> }
> protected static void OnMessage(IMessage receivedMsg)
> {
> var message =
[jira] [Updated] (AMQNET-644) Release
[ https://issues.apache.org/jira/browse/AMQNET-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-644: Fix Version/s: (was: 1.8.0) > Release > --- > > Key: AMQNET-644 > URL: https://issues.apache.org/jira/browse/AMQNET-644 > Project: ActiveMQ .Net > Issue Type: Bug > Components: Pooled >Affects Versions: 1.7.2 >Reporter: Ekkarat Wareesing >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-565. --- > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Deleted] (AMQNET-651) GOLDENBET88 磊 SBOBET ⋆ SBOBET88 ⋆ SBOBET888 ⋆ BOLA88 LIVE ⋆ SBOBET MOBILE ⋆ SBOBET LOGIN ⋆ SBOBET LINK ALTERNATIF di Agen SBOBET Terpercaya
[ https://issues.apache.org/jira/browse/AMQNET-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-651: > GOLDENBET88 磊 SBOBET ⋆ SBOBET88 ⋆ SBOBET888 ⋆ BOLA88 LIVE ⋆ SBOBET MOBILE ⋆ > SBOBET LOGIN ⋆ SBOBET LINK ALTERNATIF di Agen SBOBET Terpercaya > - > > Key: AMQNET-651 > URL: https://issues.apache.org/jira/browse/AMQNET-651 > Project: ActiveMQ .Net > Issue Type: New Feature >Reporter: sbobet >Priority: Major > Labels: bulk-closed, newbie > Original Estimate: 504h > Remaining Estimate: 504h > > h1. SBOBET | Agen SBOBET Terpercaya | Daftar SBOBET > > [!https://i.ibb.co/N75mrKY/Daftar-Goldenbet88.gif|align=center!|http://167.114.140.196/daftar/] > > [!https://i.ibb.co/BtxQhc1/4-Livechat.gif|align=center!|https://secure.livechatinc.com/licence/1501292/v2/open_chat.cgi] > [Sbobet|https://www.judibola.id/] termasuk situs judi online yang menyediakan > berbagai macam taruhan olahraga, casino, permainan klasik, pacuan kuda hingga > judi slot online. Selain itu sbobet juga menyediakan taruhan esport dan juga > termasuk virtual game yang disediakan selama 24 jam non stop. Banyak macam > pilihan permainan judi online terlengkap dan terpopular di Indonesia kini > dapat anda nikmati keseruannya diantaranya : Live Casino Online, [slot > online|https://www.aigameresearch.org/situs-slot-online-terbaik-dan-terpercaya/], > Bola Tangkas, Poker Online, Tembak ikan dan juga Togel Online. Tentu saja > semua permainan yang disediakan akan lebih mudah untuk anda mainkan cukup > dengan 1 akun untuk semua permainan dengan mudahnya anda akses di berbagai > aplikasi mobile , seperti Smartphone, PC, Notebook, Komputer, dan Laptop > dengan mudah dan aman 100% pastinya hanya di GOLDENBET88. > h2. Agen SBOBET Terpercaya GOLDENBET88 > GOLDENBET88 selaku Agen Bola Terpercaya Sbobet termasuk situs judi bola resmi > Daftar SBOBET terbaik sejak 2011 terbaik dan terpercaya dengan memberikan > rasa aman bagi semua member sbobet88 mobile dengan pasaran bola Grade A yang > di mana merupakan salah satu jenis pasaran terbaik dan terendah dibandingkan > yang lainnya. Perlu diketahui kenapa kami menawarkan Sbobet dibanding > provider judi bola online lainnya, hal ini dikarenakan bandar Sbobet Online > ini sangat mengikuti perkembangan teknologi seperti saat ini sudah ada Sbobet > Mobile yang did mana Anda semua bisa main di smartphone kesayangan baik itu > di Android maupun IOS. Jadi tidak perlu duduk di depan komputer saja. Dengan > kemudahan inilah yang membuat Sbobet jadi pilihan terbaik dan terpercaya oleh > para member judi bola dengan Dilengkapi Dengan Sistem Keamanan 100%. > Agen Sbobet Goldenbet88 juga memberikan pelayanan nomor satu bagi semua > member judi bola online yang bermain di situs bola sbobet online resmi > Indonesia. Itu juga dikarenakan Agen sbobet Indonesia yang telah bekerja sama > dengan bank ternama di Indonesia, yakni Bca, Mandiri, Cimb, BNI, BRI. Dan > ditambah dengan adanya sistem pengisian Deposit via Pulsa Telkomsel dan juga > quickpay via Ovo, Dana, Sakuku dan Gopay yang menambah kepercayaan dan > ramainya member sbobet88 mobile bermain di Goldenbet88. > h2. *Bandar Sbobet Bola Resmi Indonesia* > Dalam memainkan judi bola sbobet 88 kamu pastinya diharuskan memilih bermain > di bandar sbobet bola resmi yang telah diakui oleh semua player judi sbobet > asia dan juga Indonesia. Memang hal itu pun sangat jarang dan tentunya tak > bisa didapatkan dengan mudah. Namun Goldenbe88 pun telah diakui dengan sistem > keamanan paling secure ditambah adanya lisensi dari PACGOR dari Pemerintah > Filipina membuat bettor judi bola online semakin yakin dengan memilih dan > bermain di Situs Sbobet yang telah diberikan pelayanan lengkap untuk member > sbobet88 mobile yang bermain setiap harinya > Taruhan sepak bola mungkin tidak tampak sekecil taruhan sepak bola seluler, > tetapi nyaman untuk bermain di mana saja dan memiliki segala hal seperti > taruhan online. Melalui situs [nova88|http://51.254.58.228/] di layar > komputer Dapat memainkan semuanya, termasuk taruhan olahraga, Casino online, > live betting, permainan kasino, eSports, perjudian online yang lengkap. > Selain sebuah akun Sbobet, anda juga memerlukan sebuah sbobet88 link, > dikarenakan di Indonesia ada Internet Nawala yang diberlakukan oleh Kominfo. > Internet Nawala seperti Internet Positif dan Internet Sehat yang menghalangi > akses ke situs perjudian tentunya akan menghambat anda bermain di situs > Sbobet. > h2. LINK LOGIN SBOBET TERBARU DESKTOP (KOMPUTER/PC) > * moneyyellow.com > * sbowin.com > * monday111.com > * gabungsbo.com > * suday999.com > * wowsbo.com > * playsbo.com >
[jira] [Commented] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259285#comment-17259285 ] Michael Andre Pearce commented on AMQNET-565: - This is now released in 1.8.0 > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated AMQNET-565: Fix Version/s: 1.8.0 > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved AMQNET-565. - Resolution: Fixed > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Fix For: 1.8.0 > > Time Spent: 14h 50m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-649) bugs in PooledTaskRunner.cs
[ https://issues.apache.org/jira/browse/AMQNET-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241002#comment-17241002 ] Michael Andre Pearce commented on AMQNET-649: - https://github.com/apache/activemq-nms-openwire > bugs in PooledTaskRunner.cs > --- > > Key: AMQNET-649 > URL: https://issues.apache.org/jira/browse/AMQNET-649 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Affects Versions: 1.7.2 >Reporter: JEFF ANDERSON >Priority: Major > Attachments: PooledTaskRunner.cs > > > Although the 1.7.2 release of the AMQ .net client uses the > DedicatedTaskRunner runner by default. We compile from source and use > PooledTaskRunner.cs for performance reasons. However this code has some bugs. > Namely the Shutdown() method will deadlock on a call to Thread.Sleep with > infinite timespan. If you look at the Java source for PooledTaskRunner, it > looks like the C# port is missing the thread synchronization logic that the > Java implementation has. I've attached a version which corrects this and > makes it in-line with the Java implementation and corrects the logic in > Shutdown which needs to be a synchronized wait (e.g., Monitor.Wait()) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-649) bugs in PooledTaskRunner.cs
[ https://issues.apache.org/jira/browse/AMQNET-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241000#comment-17241000 ] Michael Andre Pearce commented on AMQNET-649: - Youll be best by opening a pr in github with both a test case demonstrating the issue along with the fix > bugs in PooledTaskRunner.cs > --- > > Key: AMQNET-649 > URL: https://issues.apache.org/jira/browse/AMQNET-649 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Affects Versions: 1.7.2 >Reporter: JEFF ANDERSON >Priority: Major > Attachments: PooledTaskRunner.cs > > > Although the 1.7.2 release of the AMQ .net client uses the > DedicatedTaskRunner runner by default. We compile from source and use > PooledTaskRunner.cs for performance reasons. However this code has some bugs. > Namely the Shutdown() method will deadlock on a call to Thread.Sleep with > infinite timespan. If you look at the Java source for PooledTaskRunner, it > looks like the C# port is missing the thread synchronization logic that the > Java implementation has. I've attached a version which corrects this and > makes it in-line with the Java implementation and corrects the logic in > Shutdown which needs to be a synchronized wait (e.g., Monitor.Wait()) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2873) Configuration Managed Queues are being auto deleted but should not.
[ https://issues.apache.org/jira/browse/ARTEMIS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated ARTEMIS-2873: -- Summary: Configuration Managed Queues are being auto deleted but should not. (was: Configuration Managed Queues are being auto deleted.) > Configuration Managed Queues are being auto deleted but should not. > --- > > Key: ARTEMIS-2873 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2873 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.14.0 >Reporter: Michael Andre Pearce >Priority: Major > > Auto Delete queues and Auto Delete created queues are meant to allow auto > deletion of queues created by clients. Configuration managed queues should > not be auto deleted, these should be deleted only by removing from > configuration, it seems there a bug where configuration managed queues can be > auto deleted, ensure this is not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2873) Configuration Managed Queues are being auto deleted.
Michael Andre Pearce created ARTEMIS-2873: - Summary: Configuration Managed Queues are being auto deleted. Key: ARTEMIS-2873 URL: https://issues.apache.org/jira/browse/ARTEMIS-2873 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 2.14.0 Reporter: Michael Andre Pearce Auto Delete queues and Auto Delete created queues are meant to allow auto deletion of queues created by clients. Configuration managed queues should not be auto deleted, these should be deleted only by removing from configuration, it seems there a bug where configuration managed queues can be auto deleted, ensure this is not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2863) Support pausing dispatch during group rebalance
Michael Andre Pearce created ARTEMIS-2863: - Summary: Support pausing dispatch during group rebalance Key: ARTEMIS-2863 URL: https://issues.apache.org/jira/browse/ARTEMIS-2863 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Affects Versions: 2.14.0 Reporter: Michael Andre Pearce Assignee: Michael Andre Pearce Currently on rebalance dispatch is not paused, as such inflight messages to a consumer when rebalanced may cause out of order issues as the new consumer maybe dispatched a message for the same group and process it faster. As such it would be good to have ability to pause dispatch when group rebalance occurs, waiting till delivering "inflight" messages are processed before re-dispatching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2822) Update docs with restart sequence,
Michael Andre Pearce created ARTEMIS-2822: - Summary: Update docs with restart sequence, Key: ARTEMIS-2822 URL: https://issues.apache.org/jira/browse/ARTEMIS-2822 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Michael Andre Pearce -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2797) Reset queue properties by unsetting them in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved ARTEMIS-2797. --- Resolution: Fixed > Reset queue properties by unsetting them in broker.xml > -- > > Key: ARTEMIS-2797 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2797 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.13.0 >Reporter: Jan Šmucr >Priority: Major > Labels: pull-request-available > Fix For: 2.14.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Currently the queue properties cannot be removed because of property new > value null checks leading to quitting the PostOfficeImpl#updateQueue() > instead of resetting the properties to their default values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2815) Null pointer exception on queue update
[
https://issues.apache.org/jira/browse/ARTEMIS-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce resolved ARTEMIS-2815.
---
Resolution: Fixed
> Null pointer exception on queue update
> --
>
> Key: ARTEMIS-2815
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2815
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Krzysztof Porębski
>Assignee: Krzysztof Porębski
>Priority: Major
> Fix For: 2.14.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Null pointer exception is thrown on the attempt to update a queue created
> without a filter.
> The problem is with getQueueConfiguration method in QueueImpl class. There is
> no check if filter is null before getFilterString is invoked.
> {code:java}
> @Override
> public QueueConfiguration getQueueConfiguration() {
>return new QueueConfiguration(name)
> .setAddress(address)
> .setId(id)
> .setRoutingType(routingType)
> .setFilterString(filter.getFilterString())
> .setDurable(isDurable())
> .setUser(user)
> .setMaxConsumers(maxConsumers)
> .setExclusive(exclusive)
> .setGroupRebalance(groupRebalance)
> .setGroupBuckets(groupBuckets)
> .setGroupFirstKey(groupFirstKey)
> .setLastValue(false)
> .setLastValue(null)
> .setNonDestructive(nonDestructive)
> .setPurgeOnNoConsumers(purgeOnNoConsumers)
> .setConsumersBeforeDispatch(consumersBeforeDispatch)
> .setDelayBeforeDispatch(delayBeforeDispatch)
> .setAutoDelete(autoDelete)
> .setAutoDeleteDelay(autoDeleteDelay)
> .setAutoDeleteMessageCount(autoDeleteMessageCount)
> .setRingSize(ringSize)
> .setConfigurationManaged(configurationManaged)
> .setTemporary(temporary)
> .setInternal(internalQueue)
> .setTransient(refCountForConsumers instanceof TransientQueueManagerImpl)
> .setAutoCreated(autoCreated);
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2815) Null pointer exception on queue update
[
https://issues.apache.org/jira/browse/ARTEMIS-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce updated ARTEMIS-2815:
--
Fix Version/s: 2.14.0
> Null pointer exception on queue update
> --
>
> Key: ARTEMIS-2815
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2815
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Krzysztof Porębski
>Assignee: Krzysztof Porębski
>Priority: Major
> Fix For: 2.14.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Null pointer exception is thrown on the attempt to update a queue created
> without a filter.
> The problem is with getQueueConfiguration method in QueueImpl class. There is
> no check if filter is null before getFilterString is invoked.
> {code:java}
> @Override
> public QueueConfiguration getQueueConfiguration() {
>return new QueueConfiguration(name)
> .setAddress(address)
> .setId(id)
> .setRoutingType(routingType)
> .setFilterString(filter.getFilterString())
> .setDurable(isDurable())
> .setUser(user)
> .setMaxConsumers(maxConsumers)
> .setExclusive(exclusive)
> .setGroupRebalance(groupRebalance)
> .setGroupBuckets(groupBuckets)
> .setGroupFirstKey(groupFirstKey)
> .setLastValue(false)
> .setLastValue(null)
> .setNonDestructive(nonDestructive)
> .setPurgeOnNoConsumers(purgeOnNoConsumers)
> .setConsumersBeforeDispatch(consumersBeforeDispatch)
> .setDelayBeforeDispatch(delayBeforeDispatch)
> .setAutoDelete(autoDelete)
> .setAutoDeleteDelay(autoDeleteDelay)
> .setAutoDeleteMessageCount(autoDeleteMessageCount)
> .setRingSize(ringSize)
> .setConfigurationManaged(configurationManaged)
> .setTemporary(temporary)
> .setInternal(internalQueue)
> .setTransient(refCountForConsumers instanceof TransientQueueManagerImpl)
> .setAutoCreated(autoCreated);
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2337) federated queues not working correctly with wildcards or defaults
[ https://issues.apache.org/jira/browse/ARTEMIS-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated ARTEMIS-2337: -- Priority: Minor (was: Critical) > federated queues not working correctly with wildcards or defaults > - > > Key: ARTEMIS-2337 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2337 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: RHEL >Reporter: Thomas Wood >Priority: Minor > > artemis1 upstream federated to artemis2. > clients consume artemis2 messages from artemis1. > client connects to artemis1 and messages are routed from artemis2 as > expected, but any new messages that land on artemis2 are not routed to > artemis1 until the client reconnects. > It seems that the issue is related to wildcards: > include-federated="false"> > > > The following config works as expected with the client receiving message > prior to and during the life of client connection: > include-federated="false"> > > > also noticed that the following causes the issue too: > include-federated="false"> > > > > but this works: > include-federated="false"> > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Deleted] (AMQNET-641) Graphic designing services near me
[ https://issues.apache.org/jira/browse/AMQNET-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce deleted AMQNET-641: > Graphic designing services near me > -- > > Key: AMQNET-641 > URL: https://issues.apache.org/jira/browse/AMQNET-641 > Project: ActiveMQ .Net > Issue Type: New Feature >Reporter: harry johns >Priority: Major > > Digital Marketing Services India is a New Delhi based leading Internet > Marketing Agency. We offer quality and affordable digital marketing services > worldwide. We start with a professional and effective website, sparkle it > with excellent SEO, bridge it with social networks and create your business > broadcast channel to bring in the customers. > https://auroravista.tech/services/graphic-designing/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-640) ArgumentOutOfRangeException in StringBuilder.ToString() after updating from 1.8.0 to 1.8.1
[ https://issues.apache.org/jira/browse/AMQNET-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141900#comment-17141900 ] Michael Andre Pearce commented on AMQNET-640: - [~havret] - ping have you seen this? > ArgumentOutOfRangeException in StringBuilder.ToString() after updating from > 1.8.0 to 1.8.1 > -- > > Key: AMQNET-640 > URL: https://issues.apache.org/jira/browse/AMQNET-640 > Project: ActiveMQ .Net > Issue Type: Bug >Affects Versions: 1.7.2 >Reporter: Marc Gerritsen >Priority: Major > > After updating from 1.8.0 to 1.8.1 I get this error. The internet expects the > access to the StringBuilder is not thread save. > Index was out of range. Must be non-negative and less than the size of the > collection. (Parameter 'chunkLength') System.ArgumentOutOfRangeException > ArgumentOutOfRangeException System.ArgumentOutOfRangeException: Index was out > of range. Must be non-negative and less than the size of the collection. > (Parameter 'chunkLength') > at System.Text.StringBuilder.ToString() > at Apache.NMS.AMQP.Message.DefaultMessageIdBuilder.CreateMessageId(String > producerId, Int64 messageSequence) > at Apache.NMS.AMQP.NmsSession.Send(NmsMessageProducer producer, IDestination > destination, IMessage original, MsgDeliveryMode deliveryMode, MsgPriority > priority, TimeSpan timeToLive, Boolean disableMessageId, Boolean > disableMessageTimestamp) > at Apache.NMS.AMQP.NmsMessageProducer.Send(IDestination destination, IMessage > message, MsgDeliveryMode deliveryMode, MsgPriority priority, TimeSpan > timeToLive) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-641) Graphic designing services near me
[ https://issues.apache.org/jira/browse/AMQNET-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-641. --- > Graphic designing services near me > -- > > Key: AMQNET-641 > URL: https://issues.apache.org/jira/browse/AMQNET-641 > Project: ActiveMQ .Net > Issue Type: New Feature >Reporter: harry johns >Priority: Major > > Digital Marketing Services India is a New Delhi based leading Internet > Marketing Agency. We offer quality and affordable digital marketing services > worldwide. We start with a professional and effective website, sparkle it > with excellent SEO, bridge it with social networks and create your business > broadcast channel to bring in the customers. > https://auroravista.tech/services/graphic-designing/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-641) Graphic designing services near me
[ https://issues.apache.org/jira/browse/AMQNET-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-641. --- Resolution: Fixed > Graphic designing services near me > -- > > Key: AMQNET-641 > URL: https://issues.apache.org/jira/browse/AMQNET-641 > Project: ActiveMQ .Net > Issue Type: New Feature >Reporter: harry johns >Priority: Major > > Digital Marketing Services India is a New Delhi based leading Internet > Marketing Agency. We offer quality and affordable digital marketing services > worldwide. We start with a professional and effective website, sparkle it > with excellent SEO, bridge it with social networks and create your business > broadcast channel to bring in the customers. > https://auroravista.tech/services/graphic-designing/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (AMQNET-641) Graphic designing services near me
[ https://issues.apache.org/jira/browse/AMQNET-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce reopened AMQNET-641: - > Graphic designing services near me > -- > > Key: AMQNET-641 > URL: https://issues.apache.org/jira/browse/AMQNET-641 > Project: ActiveMQ .Net > Issue Type: New Feature >Reporter: harry johns >Priority: Major > > Digital Marketing Services India is a New Delhi based leading Internet > Marketing Agency. We offer quality and affordable digital marketing services > worldwide. We start with a professional and effective website, sparkle it > with excellent SEO, bridge it with social networks and create your business > broadcast channel to bring in the customers. > https://auroravista.tech/services/graphic-designing/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2787) Allow a queue to be disabled, so that messages are not routed to it.
Michael Andre Pearce created ARTEMIS-2787: - Summary: Allow a queue to be disabled, so that messages are not routed to it. Key: ARTEMIS-2787 URL: https://issues.apache.org/jira/browse/ARTEMIS-2787 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Reporter: Michael Andre Pearce There are a number of scenarios where it can be useful to disable a queue, so messages are not routed to it. 1) An issue that requires investigation but you wish to keep the consumers active, but do not wish to have message build up on the broker 2) you want to connect consumers to a address, but you do not wish the flow to start and wish to manage the enablement and disablement centrally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQNET-637) NMS 2.0
Michael Andre Pearce created AMQNET-637: --- Summary: NMS 2.0 Key: AMQNET-637 URL: https://issues.apache.org/jira/browse/AMQNET-637 Project: ActiveMQ .Net Issue Type: Improvement Components: NMS Affects Versions: 1.8.0 Reporter: Michael Andre Pearce Fix For: 2.0.0 NMS API is still at JMS 1.1 api level, this is to update the NMS api to the latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2665) AMQP Shared Non Durable queues are not being created same as CORE
Michael Andre Pearce created ARTEMIS-2665: - Summary: AMQP Shared Non Durable queues are not being created same as CORE Key: ARTEMIS-2665 URL: https://issues.apache.org/jira/browse/ARTEMIS-2665 Project: ActiveMQ Artemis Issue Type: Task Reporter: Michael Andre Pearce This means that they are not being cleaned up properly if a message is left in the queue, as queue hasnt been marked temporary -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2476) New MQTT subscriptions receive older (not last published) retained message.
[ https://issues.apache.org/jira/browse/ARTEMIS-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved ARTEMIS-2476. --- Fix Version/s: 2.12.0 Resolution: Fixed > New MQTT subscriptions receive older (not last published) retained message. > --- > > Key: ARTEMIS-2476 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2476 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.10.0, 2.10.1 >Reporter: Assen Sharlandjiev >Priority: Blocker > Fix For: 2.12.0 > > Time Spent: 2h > Remaining Estimate: 0h > > I have observed that new MQTT subscriptions on a given topic, receive older > retained messages. Instead of getting the latest retained message published > on the topic, the new subscription received an older message, published > before that last one. > > I have created a [mqtt-test|https://github.com/assens/mqtt-test] project that > demonstrated the problem. Check the readme, and run the Artemis broker test: > > mvn -Dtest=ArtemisTest verify > > The test project contains multiple MQTT brokers tests. Only Artemis broker > tests fail. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-1194) SOCKS proxy support
[ https://issues.apache.org/jira/browse/ARTEMIS-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved ARTEMIS-1194. --- Fix Version/s: 2.12.0 Resolution: Fixed > SOCKS proxy support > --- > > Key: ARTEMIS-1194 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1194 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Andrius Dagys >Priority: Minor > Fix For: 2.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add SOCKS4a & 5 support to the NettyConnector. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2646) Allow setting message properties when sending messages via REST
[ https://issues.apache.org/jira/browse/ARTEMIS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved ARTEMIS-2646. --- Fix Version/s: 2.12.0 Resolution: Fixed > Allow setting message properties when sending messages via REST > --- > > Key: ARTEMIS-2646 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2646 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Michael Andre Pearce >Priority: Major > Fix For: 2.12.0 > > > Allow setting message properties on a message posted via REST interface. The > property is transferred as a HTTP header having name prefixed with > "mesage.property.". On successful arrival on address resource the prefix is > stripped and property set as message property. This allows filtering on > custom fields and using other broker features requiring message properties > set (i.e AMQ_GROUP_ID). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2646) Allow setting message properties when sending messages via REST
Michael Andre Pearce created ARTEMIS-2646: - Summary: Allow setting message properties when sending messages via REST Key: ARTEMIS-2646 URL: https://issues.apache.org/jira/browse/ARTEMIS-2646 Project: ActiveMQ Artemis Issue Type: Task Reporter: Michael Andre Pearce Allow setting message properties on a message posted via REST interface. The property is transferred as a HTTP header having name prefixed with "mesage.property.". On successful arrival on address resource the prefix is stripped and property set as message property. This allows filtering on custom fields and using other broker features requiring message properties set (i.e AMQ_GROUP_ID). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2644) Include client id into non durable subscriber queue name
[ https://issues.apache.org/jira/browse/ARTEMIS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054196#comment-17054196 ] Michael Andre Pearce commented on ARTEMIS-2644: --- As discussed in PRs, if a user wished to control queue name with JMS 2.0 for non durable's they can make a shared non durable subscription, making a unique subscription name per client. Changing default naming of objects, would be impactful to all users, so is a -1 change. If additional meta data to identify what/whom created a queue this can be added the Queue, as like the user was added the other year, e.g. clientid and remote address could be added the queue impl and then exposed up via imx making it available to any metrics system and within the console. > Include client id into non durable subscriber queue name > > > Key: ARTEMIS-2644 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2644 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 7h 50m > Remaining Estimate: 0h > > In many cases, we have users who can start up a java web start based user > interface, to receive notifications about events that may require manual > intervention. > For these, we typically use non-durable, non shared subscriptions. > These are identified in the broker only with a computed UID, ie a non durable > subscriber queue name: 4bd56221-3920-47e9-b5c1-f12015174d4d > Sometimes, these consumers can stop consuming, possibly through the user not > exiting cleanly, or perhaps with the virtualised desktop environment pausing > the UI. > We can look to killl these connections / queues from the broker side, but > since there is no hostname / application / user visible in the queue name, it > makes it hard to identify impacted business users. > This is a request to allow consuming applications to provide their own string > as part of the queue name, to assist with troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2644) Include client id into non durable subscriber queue name
[ https://issues.apache.org/jira/browse/ARTEMIS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce updated ARTEMIS-2644: -- Fix Version/s: (was: 2.12.0) > Include client id into non durable subscriber queue name > > > Key: ARTEMIS-2644 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2644 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 7h 50m > Remaining Estimate: 0h > > In many cases, we have users who can start up a java web start based user > interface, to receive notifications about events that may require manual > intervention. > For these, we typically use non-durable, non shared subscriptions. > These are identified in the broker only with a computed UID, ie a non durable > subscriber queue name: 4bd56221-3920-47e9-b5c1-f12015174d4d > Sometimes, these consumers can stop consuming, possibly through the user not > exiting cleanly, or perhaps with the virtualised desktop environment pausing > the UI. > We can look to killl these connections / queues from the broker side, but > since there is no hostname / application / user visible in the queue name, it > makes it hard to identify impacted business users. > This is a request to allow consuming applications to provide their own string > as part of the queue name, to assist with troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-2644) Include client id into non durable subscriber queue name
[ https://issues.apache.org/jira/browse/ARTEMIS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce reopened ARTEMIS-2644: --- > Include client id into non durable subscriber queue name > > > Key: ARTEMIS-2644 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2644 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Bruscino >Priority: Major > Fix For: 2.12.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > In many cases, we have users who can start up a java web start based user > interface, to receive notifications about events that may require manual > intervention. > For these, we typically use non-durable, non shared subscriptions. > These are identified in the broker only with a computed UID, ie a non durable > subscriber queue name: 4bd56221-3920-47e9-b5c1-f12015174d4d > Sometimes, these consumers can stop consuming, possibly through the user not > exiting cleanly, or perhaps with the virtualised desktop environment pausing > the UI. > We can look to killl these connections / queues from the broker side, but > since there is no hostname / application / user visible in the queue name, it > makes it hard to identify impacted business users. > This is a request to allow consuming applications to provide their own string > as part of the queue name, to assist with troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2547) AMQP Client reconnect fails on broker stop start
Michael Andre Pearce created ARTEMIS-2547: - Summary: AMQP Client reconnect fails on broker stop start Key: ARTEMIS-2547 URL: https://issues.apache.org/jira/browse/ARTEMIS-2547 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP, Broker Affects Versions: 2.10.1, 2.7.0 Reporter: Michael Andre Pearce Assignee: Michael Andre Pearce Fix For: 2.11.0 When a broker is stopped and started, e.g. network pinger or other reasons, amqp clients with reconnect logic, e.g. qpid jms client, do not successfully reconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQNET-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce updated AMQNET-422:
Fix Version/s: (was: 1.8.0)
> Added support for transactions for Asyncronous Listeners
>
>
> Key: AMQNET-422
> URL: https://issues.apache.org/jira/browse/AMQNET-422
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: ActiveMQ
>Reporter: Remo Gloor
>Priority: Minor
> Attachments: AddedSupportForAmbientTransactionForAsyncConsumers -
> When_AMQNET-413_IsFixed.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> allDTCImprovments.patch
>
>
> Asyncronous Listeners do not support transactions properly. I suggest to add
> the option to register a callback that can be used to create a transaction
> for each message received by the asyncronous listener.
> e.g.
> ((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
> this.CreateScope;
> private TransactionScope CreateScope()
> {
> return new TransactionScope(TransactionScopeOption.RequiresNew);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (AMQNET-628) Update AMQP csproj versions to 1.8.1 for next release
[ https://issues.apache.org/jira/browse/AMQNET-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce resolved AMQNET-628. - Resolution: Fixed > Update AMQP csproj versions to 1.8.1 for next release > - > > Key: AMQNET-628 > URL: https://issues.apache.org/jira/browse/AMQNET-628 > Project: ActiveMQ .Net > Issue Type: Task > Components: AMQP >Affects Versions: 1.8.1 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: 1.8.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQNET-628) Update AMQP csproj versions to 1.8.1 for next release
Michael Andre Pearce created AMQNET-628: --- Summary: Update AMQP csproj versions to 1.8.1 for next release Key: AMQNET-628 URL: https://issues.apache.org/jira/browse/AMQNET-628 Project: ActiveMQ .Net Issue Type: Task Components: AMQP Affects Versions: 1.8.1 Reporter: Michael Andre Pearce Fix For: 1.8.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-619) Remote detach is not handled properly for sender link
[ https://issues.apache.org/jira/browse/AMQNET-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-619. --- > Remote detach is not handled properly for sender link > - > > Key: AMQNET-619 > URL: https://issues.apache.org/jira/browse/AMQNET-619 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Remote detach is not handled properly for sender link. MessageProducer is > created even if no link terminus was created. It results in unexpected > behavior if we try to use MessageProducer immediately after its creation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-626) TriggerReconnectionAttempt method in FailoverProvider is not awaited
[ https://issues.apache.org/jira/browse/AMQNET-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-626. --- > TriggerReconnectionAttempt method in FailoverProvider is not awaited > > > Key: AMQNET-626 > URL: https://issues.apache.org/jira/browse/AMQNET-626 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Minor > Fix For: 1.8.0 > > > **We should revisit FailoverProvider implementation and resolve the issue > with TriggerReconnectionAttempt method not being awaited. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-624) Failover issue when broker sends open frame and shortly after close frame
[ https://issues.apache.org/jira/browse/AMQNET-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-624. --- > Failover issue when broker sends open frame and shortly after close frame > - > > Key: AMQNET-624 > URL: https://issues.apache.org/jira/browse/AMQNET-624 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Critical > Fix For: 1.8.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We are observing an issue with failover implementation. Everything works as > expected, when there is no connection to the broker. Provider try to obtain a > new connection and reties until it gets it. However if broker sends open > frame and shortly after close frame, the reconnect process is disrupted and > connection never restored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-617) Support Message Selectors
[ https://issues.apache.org/jira/browse/AMQNET-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-617. --- > Support Message Selectors > - > > Key: AMQNET-617 > URL: https://issues.apache.org/jira/browse/AMQNET-617 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: AMQP >Affects Versions: 1.8.0 >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Current implementation of message selectors doesn't work with Apache Artemis. > It should be implemented the same way as in qpid-jms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-620) ConnectionFactory is not initialized properly with Uri overload
[ https://issues.apache.org/jira/browse/AMQNET-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-620. --- > ConnectionFactory is not initialized properly with Uri overload > --- > > Key: AMQNET-620 > URL: https://issues.apache.org/jira/browse/AMQNET-620 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > ConnectionFactory is not initialized properly with constructor that takes > System.Uri as a parameter. Additional properties that are specified in broker > uri (like username or password) are not applied on connection factory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-618) Support noLocal filter
[ https://issues.apache.org/jira/browse/AMQNET-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-618. --- > Support noLocal filter > -- > > Key: AMQNET-618 > URL: https://issues.apache.org/jira/browse/AMQNET-618 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add support for noLocal message filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-611) Apache.NMS.IllegalStateException is throw on transport thread
[
https://issues.apache.org/jira/browse/AMQNET-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce closed AMQNET-611.
---
> Apache.NMS.IllegalStateException is throw on transport thread
> -
>
> Key: AMQNET-611
> URL: https://issues.apache.org/jira/browse/AMQNET-611
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: AMQP, NMS
>Reporter: Chris Morgan
>Priority: Major
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found this while looking at changes for AMQNET-610. While trying to shutdown
> a connection the NMS amqp provider throws an exception on the transport
> thread.
> Havret has proposed a solution in PR 29, see
> https://github.com/apache/activemq-nms-amqp/pull/29#issuecomment-530123108
> Here is the exception:
> {noformat}
> Exception occurred: Apache.NMS.IllegalStateException: The Session is closed
> at Apache.NMS.AMQP.NmsSession.CheckClosed()
> at Apache.NMS.AMQP.NmsSession.get_AcknowledgementMode()
> at
> Apache.NMS.AMQP.NmsMessageConsumer.SetAcknowledgeCallback(InboundMessageDispatch
> envelope)
> at Apache.NMS.AMQP.NmsMessageConsumer.OnInboundMessage(InboundMessageDispatch
> envelope)
> at Apache.NMS.AMQP.NmsSession.OnInboundMessage(InboundMessageDispatch
> envelope)
> at Apache.NMS.AMQP.NmsConnection.OnInboundMessage(InboundMessageDispatch
> envelope)
> at
> Apache.NMS.AMQP.Provider.Failover.FailoverProvider.OnInboundMessage(InboundMessageDispatch
> envelope)
> at Apache.NMS.AMQP.Provider.Amqp.AmqpConsumer.OnMessage(IReceiverLink
> receiver, Message amqpMessage)
> at Amqp.ReceiverLink.OnTransfer(Delivery delivery, Transfer transfer,
> ByteBuffer buffer)
> at Amqp.Session.OnTransfer(Transfer transfer, ByteBuffer buffer)
> at Amqp.Connection.OnFrame(ByteBuffer buffer)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (AMQNET-614) Extend logging to make debugging easier
[ https://issues.apache.org/jira/browse/AMQNET-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-614. --- > Extend logging to make debugging easier > --- > > Key: AMQNET-614 > URL: https://issues.apache.org/jira/browse/AMQNET-614 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: AMQP >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During work on AMQNET-610 I needed to extend some logs in order to track down > a few nasty issues that were occurring only on slower boxes. I'm not sure if > we need all of the changes merged, but some bits might be quite useful for > future dubbing on CI if the need arises. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-616) Add TCP Keep-Alive support
[ https://issues.apache.org/jira/browse/AMQNET-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-616. --- > Add TCP Keep-Alive support > -- > > Key: AMQNET-616 > URL: https://issues.apache.org/jira/browse/AMQNET-616 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: AMQP >Affects Versions: 1.8.0 >Reporter: Krzysztof Porebski >Priority: Major > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It should be possible to enable TCP Keep-Alive option for underlying socket. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (AMQNET-605) Pre-buffered messages aren't released when consumer closes down
[ https://issues.apache.org/jira/browse/AMQNET-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Andre Pearce closed AMQNET-605. --- > Pre-buffered messages aren't released when consumer closes down > --- > > Key: AMQNET-605 > URL: https://issues.apache.org/jira/browse/AMQNET-605 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Affects Versions: 1.8.0 >Reporter: Krzysztof Porebski >Priority: Minor > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Failing unit test > ConsumerIntegrationTest.cs --> > TestCloseDurableSubscriberWithUnackedAndUnconsumedPrefetchedMessages -- This message was sent by Atlassian Jira (v8.3.4#803005)
