[jira] [Commented] (AMQ-3166) client calls to createProducer() and send() successful even though BrokerFilter methods throw exceptions
[
https://issues.apache.org/jira/browse/AMQ-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915455#comment-13915455
]
Arthur Naseef commented on AMQ-3166:
Anyone with thoughts on (a) the best approach to resolving this, and (b)
avoiding reduced performance, please speak up.
> client calls to createProducer() and send() successful even though
> BrokerFilter methods throw exceptions
>
>
> Key: AMQ-3166
> URL: https://issues.apache.org/jira/browse/AMQ-3166
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
>Affects Versions: 5.4.2, 5.5.0
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
> Attachments: AMQ3166Test.java, AMQ3166Test.java,
> FailedTransactionTracking.java, FailedTransactionTrackingPlugin.java
>
>
> Client calls to createProducer() always return without an error even though a
> BrokerFilter's addProducer() method throws an exception on the request. In
> contrast, createConsumer() throws an exception, as expected, when
> BrokerFilter's addConsumer() throws an exception.
> Clients using transacted sessions always return successfully from send() when
> a BrokerFilter's send() method throws an exception.
> Below is a broker configuration file using to
> illustrate the problem.
> To reproduce the problem With this configuration, a test client only needs to
> connect with user = "user" and password = "password", and then attempt to
> produce messages with a transacted session to any queue other than ABC (e.g.
> DEF).
> Tracing the cause of the issue has lead to finding that the client code for
> creating a producer uses an Async send for the producer information. The
> analogous code for consumers uses a Sync send.
> I will work on a patch. It would be very helpful to have feedback on the
> operation of the bus and the best way to resolve this problem. Based on my
> research, it seems that createProducer() should be using a Sync send in place
> of the Async one. Not yet sure about send(). Another possibility is to move
> the security operations to earlier in the internal broker flow.
> === SAMPLE BROKER XML ===
>xmlns="http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd";>
> http://activemq.apache.org/schema/core";
> brokerName="localhost"
> dataDirectory="${activemq.base}/data"
> destroyApplicationContextOnStop="true" >
>
>
>
>
>
>
>
> groups="users"/>
>
>
>
>
>
>
>write="users" admin="users" />
>read="users" write="users" admin="users" />
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQ-3166) client calls to createProducer() and send() successful even though BrokerFilter methods throw exceptions
[
https://issues.apache.org/jira/browse/AMQ-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915454#comment-13915454
]
Arthur Naseef commented on AMQ-3166:
Let's get this fixed. It's a violation of the JMS spec that transactions are
not reliable.
I see two options.
* Make the client libraries perform sends synchronously.
* Have the broker retain state of failures and propogate failed sends to failed
commits.
** Consider a way to propogate failures quickly so that a producer with large
numbers of messages does not waste all that effort only to have the commit fail
a long time later.
The downside of the first option is a likely loss of performance. However, the
second option is more complex to code and prevents possible intelligence in
clients to perform better handling of issues like individual failed sends in a
transaction (consider a client wanting to have logic to recover from a single
failed send in a larger transaction).
> client calls to createProducer() and send() successful even though
> BrokerFilter methods throw exceptions
>
>
> Key: AMQ-3166
> URL: https://issues.apache.org/jira/browse/AMQ-3166
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
>Affects Versions: 5.4.2, 5.5.0
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
> Attachments: AMQ3166Test.java, AMQ3166Test.java,
> FailedTransactionTracking.java, FailedTransactionTrackingPlugin.java
>
>
> Client calls to createProducer() always return without an error even though a
> BrokerFilter's addProducer() method throws an exception on the request. In
> contrast, createConsumer() throws an exception, as expected, when
> BrokerFilter's addConsumer() throws an exception.
> Clients using transacted sessions always return successfully from send() when
> a BrokerFilter's send() method throws an exception.
> Below is a broker configuration file using to
> illustrate the problem.
> To reproduce the problem With this configuration, a test client only needs to
> connect with user = "user" and password = "password", and then attempt to
> produce messages with a transacted session to any queue other than ABC (e.g.
> DEF).
> Tracing the cause of the issue has lead to finding that the client code for
> creating a producer uses an Async send for the producer information. The
> analogous code for consumers uses a Sync send.
> I will work on a patch. It would be very helpful to have feedback on the
> operation of the bus and the best way to resolve this problem. Based on my
> research, it seems that createProducer() should be using a Sync send in place
> of the Async one. Not yet sure about send(). Another possibility is to move
> the security operations to earlier in the internal broker flow.
> === SAMPLE BROKER XML ===
>xmlns="http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd";>
> http://activemq.apache.org/schema/core";
> brokerName="localhost"
> dataDirectory="${activemq.base}/data"
> destroyApplicationContextOnStop="true" >
>
>
>
>
>
>
>
> groups="users"/>
>
>
>
>
>
>
>write="users" admin="users" />
>read="users" write="users" admin="users" />
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQCPP-535) Activemq session commit, not working as expected.
[ https://issues.apache.org/jira/browse/AMQCPP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915452#comment-13915452 ] Arthur Naseef commented on AMQCPP-535: -- So, transactions are not the most reliable form of producing message, as the JMS spec requires? > Activemq session commit, not working as expected. > - > > Key: AMQCPP-535 > URL: https://issues.apache.org/jira/browse/AMQCPP-535 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: CMS Impl >Affects Versions: 3.8.2 >Reporter: D V Gangadhar Rao >Assignee: Timothy Bish > > Tested with AMQ CMS CPP 3.8.2 client > Producer has opened the session in SESSION_TRANSACTED mode. > It has sent a set of messages to the destination activemq broker. > The producer did a commit on the session, which resulted in only committing > only a subset of messages in the destination queue and remaining messages are > not commited in case of a scenario where there was a queue full exception. > Expected behavior: > Actually we were expecting that session commit call should either commit the > whole batch of messages or rollback the entire batch of messages if the queue > is FULL on the destination broker queue, but it should not commit few > messages and rollback the other messages. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (AMQ-3166) client calls to createProducer() and send() successful even though BrokerFilter methods throw exceptions
[
https://issues.apache.org/jira/browse/AMQ-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef reassigned AMQ-3166:
--
Assignee: Arthur Naseef
> client calls to createProducer() and send() successful even though
> BrokerFilter methods throw exceptions
>
>
> Key: AMQ-3166
> URL: https://issues.apache.org/jira/browse/AMQ-3166
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
>Affects Versions: 5.4.2, 5.5.0
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
> Attachments: AMQ3166Test.java, AMQ3166Test.java,
> FailedTransactionTracking.java, FailedTransactionTrackingPlugin.java
>
>
> Client calls to createProducer() always return without an error even though a
> BrokerFilter's addProducer() method throws an exception on the request. In
> contrast, createConsumer() throws an exception, as expected, when
> BrokerFilter's addConsumer() throws an exception.
> Clients using transacted sessions always return successfully from send() when
> a BrokerFilter's send() method throws an exception.
> Below is a broker configuration file using to
> illustrate the problem.
> To reproduce the problem With this configuration, a test client only needs to
> connect with user = "user" and password = "password", and then attempt to
> produce messages with a transacted session to any queue other than ABC (e.g.
> DEF).
> Tracing the cause of the issue has lead to finding that the client code for
> creating a producer uses an Async send for the producer information. The
> analogous code for consumers uses a Sync send.
> I will work on a patch. It would be very helpful to have feedback on the
> operation of the bus and the best way to resolve this problem. Based on my
> research, it seems that createProducer() should be using a Sync send in place
> of the Async one. Not yet sure about send(). Another possibility is to move
> the security operations to earlier in the internal broker flow.
> === SAMPLE BROKER XML ===
>xmlns="http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd";>
> http://activemq.apache.org/schema/core";
> brokerName="localhost"
> dataDirectory="${activemq.base}/data"
> destroyApplicationContextOnStop="true" >
>
>
>
>
>
>
>
> groups="users"/>
>
>
>
>
>
>
>write="users" admin="users" />
>read="users" write="users" admin="users" />
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: How to delay consuming messages after connecting to a broker?
How about using dependencies in spring to force the connection or consumer to start last? -- View this message in context: http://activemq.2283324.n4.nabble.com/How-to-delay-consuming-messages-after-connecting-to-a-broker-tp4678361p4678402.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [jira] [Commented] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
Did I read that correctly - there's a possible concern that "disk writes are too fast"? -- View this message in context: http://activemq.2283324.n4.nabble.com/jira-Commented-AMQ-5077-Improve-performance-of-ConcurrentStoreAndDispatch-tp4678395p4678401.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Commented] (AMQ-5055) Webconsole copy of message keeps message ID and leads to failures
[
https://issues.apache.org/jira/browse/AMQ-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915438#comment-13915438
]
Arthur Naseef commented on AMQ-5055:
Tracking the code path, it appears BrokerSupport.doResend() is used to copy and
resend the message.
Even though the message is copied, the message id is not changed. Is it safe
to modify that method to change the message id after copying? What use-case
exists for keeping the same message id?
> Webconsole copy of message keeps message ID and leads to failures
> -
>
> Key: AMQ-5055
> URL: https://issues.apache.org/jira/browse/AMQ-5055
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, webconsole
> Environment: activemq-5.10-SNAPSHOT up to commit
> ec249f4dac29b0b566703b9235f25aacfa2b6ac6
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Minor
>
> Using the webconsole copy option for a persistent message to copy the message
> more than once to the same destination queue leads to problems.
> The second copy of the message will increase the Queue size and enqueue
> counter, but does not actually place a message in the Queue, whether or not
> the earlier copy is still in the Queue. In addition, the following error
> message is logged by the broker.
> {noformat}
> WARN | duplicate message from store
> ID:Arthur-Naseefs-MacBook-Pro.local-61946-1392522408304-3:2:1:1:3,
> redirecting for dlq processing
> {noformat}
> Note that this was not tested across broker restarts. Non-Persistent
> messages do not appear to have this problem.
> It seems that maintaining the message ID across copies is causing problems.
> Creating a completely new message ID should be the simplest solution.
> Perhaps storing the original message ID in a property (e.g.
> JMSXSourceMessageId) on the new message would be useful in case anyone wants
> to be able to detect the copy and determine from which message it was created.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914756#comment-13914756 ] Richard Wagg commented on AMQ-5077: --- Hi, Attached is some more different test configurations i've tried and results. Nothing seems to massively affect the throughput for better or worse. In none of the tests have the consumers had any message backlog. To try and sum up the problem: - Under normal operation we want our producers to remain unblocked for as long as possible (flow control is fine, but that to me means that the producer works uninterrupted up until a memory/disk limit is reached, then PFC kicks in, rather than a gradual degradation). - Clients all run in CLIENT_ACK mode - messages are ACKed one by one. - Both the diskstore and the network are relatively quick - tests running against topics show a roundtrip time of ~ 0.740ms (producer -> broker -> consumer -> broker -> producer reply). - The ability of the producers to send messages is currently limited by some TCP level limitation, due to the amount of work the broker is doing on it's receive threads. - The observed behaviour in producer code is that whether sending sync or async, the call to producer.send() just blocks - so even async sends are affected by JMS throughput, in a manner which isn't flow control. - In none of our tests have the consumers ever had a large pending message count - the blocking factor is not consumer speed or memory/queue limits. - Taking thread dumps throughout these tests, we can see contention around the synchronised access points in MessageDatabase - the process() method taking arguments KahaAddMessageCommand and KahaRemoveMessageCommand both lock around the page index. - Any sort of option to batch consumer acks might remove the number of single messages removed, but would also delay the ACKs to the point where more is written to the store. - Some options in the JMS (ConcurrentStoreAndDispatch) are supposed to allow optimisations in this scenario, but appear to have limited or no effect. I think there are 2 options for the root problem: 1. Disk writes are too quick (or too many disk writes are allowed to be in progress) - by the time the roundtrip from broker -> consumer and back completes, the kahaDb write is already done or in progress. 2. Thread contention stops the ACKs arriving in time to prevent the diskstore writes from happening, negating the benefit of allowing concurrentStoreAndDispatch from a performance point of view (clients might receive messages quicker, but broker still has to add and remove each message serially from the diskstore). I think the second option is most likely - we're effectively doing a lot of disk based work that we don't need to do, just because the consumer ACKs aren't coming back quick enough or aren't able to be received before the disk write is in progress, causing a double hit on both thread synchronisation, and then again at the disk level adding and removing the same message inside a small timeframe. Ideas welcome for configurations to try or areas to look at. Stuff i'm going to try: - Add some debug logging to see the queue length of the asyncQueueJobQueue in KahaDBStore - Changing client ack mode - optimizeAcknowledge, DUPS_OK_ACK etc. Don't think it'll have much effect but it's something else to rule out. I would be interested in trying any code which would allow the disk writes to go on a delay queue - something along the lines of dispatch straight away, only write to kahaDB if the ACK hasn't arrived after a configurable interval. I'm still not sure that a lot of this work should be done on the NIO send threads - even if the contention on the kahaDb store needs to be allowed to happen, i would expect requests to be allowed to queue up in memory, until a PFC limit kicks in. Until that point i wouldn't expect producer send performance to be affected. Diskstore performance for comparison: [activemq@londngnfrjms01 lib]$ /opt/java/x64/jdk1.7.0_51/bin/java -cp activemq-kahadb-store-5.9.0.redhat-610350.jar org.apache.activemq.store.kahadb.disk.util.DiskBenchmark /jms_vsp/activemq-rh590/data/test.dat Benchmarking: /jms_vsp/activemq-rh590/data/test.dat Writes: 1023993 writes of size 4096 written in 10.69 seconds. 95789.805 writes/second. 374.17892 megs/second. Sync Writes: 49746 writes of size 4096 written in 10.001 seconds. 4974.1025 writes/second. 19.430088 megs/second. Reads: 5468429 reads of size 4096 read in 10.001 seconds. 546788.25 writes/second. 2135.8916 megs/second." > Improve performance of ConcurrentStoreAndDispatch > - > > Key: AMQ-5077 > URL: https://issues.apache.org/jira/browse/AMQ-5077 > Project: ActiveMQ > Issue Type: Wish > Components: Message Store >Affects V
[jira] [Updated] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Wagg updated AMQ-5077: -- Attachment: Test combinations.xlsx > Improve performance of ConcurrentStoreAndDispatch > - > > Key: AMQ-5077 > URL: https://issues.apache.org/jira/browse/AMQ-5077 > Project: ActiveMQ > Issue Type: Wish > Components: Message Store >Affects Versions: 5.9.0 > Environment: 5.9.0.redhat-610343 >Reporter: Jason Shepherd >Priority: Minor > Attachments: Test combinations.xlsx, compDesPerf.tar.gz > > > We have publishers publishing to a topic which has 5 topic -> queue routings, > and gets a max message rate attainable of ~833 messages/sec, with each > message around 5k in size. > To test this i set up a JMS config with topic queues: > Topic > TopicRouted.1 > ... > TopicRouted.11 > Each topic has an increasing number of routings to queues, and a client is > set up to subscribe to all the queues. > Rough message rates: > routings messages/sec > 0 2500 > 1 1428 > 2 2000 > 3 1428 > 4 > 5 833 > This occurs whether the broker config has producerFlowControl="false" set to > true or false , and KahaDB disk synching is turned off. We also tried > experimenting with concurrentStoreAndDispatch, but that didn't seem to help. > LevelDB didn't give any notable performance improvement either. > We also have asyncSend enabled on the producer, and have a requirement to use > persistent messages. We have also experimented with sending messages in a > transaction, but that hasn't really helped. > It seems like producer throughput rate across all queue destinations, all > connections and all publisher machines is limited by something on the broker, > through a mechanism which is not producer flow control. I think the prime > suspect is still contention on the index. > We did some test with Yourkit profiler. > Profiler was attached to broker at startup, allowed to run and then a topic > publisher was started, routing to 5 queues. > Profiler statistics were reset, the publisher allowed to run for 60 seconds, > and then profiling snapshot was taken. During that time, ~9600 messages were > logged as being sent for a rate of ~160/sec. > This ties in roughly with the invocation counts recorded in the snapshot (i > think) - ~43k calls. > From what i can work out, in the snapshot (filtering everything but > org.apache.activemq.store.kahadb), > For the 60 second sample period, > 24.8 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, > MessageAck). > 18.3 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, > Message, boolean). > From these, a further large portion of the time is spent inside > MessageDatabase: > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, > Location) - 10 secs elapsed > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, > Location) - 8.5 secs elapsed. > As both of these lock on indexLock.writeLock(), and both take place on the > NIO transport threads, i think this accounts for at least some of the message > throughput limits. As messages are added and removed from the index one by > one, regardless of sync type settings, this adds a fair amount of overhead. > While we're not synchronising on writes to disk, we are performing work on > the NIO worker thread which can block on locks, and could account for the > behaviour we've seen client side. > To Reproduce: > 1. Install a broker and use the attached configuration. > 2. Use the 5.8.0 example ant script to consume from the queues, > TopicQueueRouted.1 - 5. eg: >ant consumer -Durl=tcp://localhost:61616 -Dsubject=TopicQueueRouted.1 > -Duser=admin -Dpassword=admin -Dmax=-1 > 3. Use the modified version of 5.8.0 example ant script (attached) to send > messages to topics, TopicRouted.1 - 5, eg: >ant producer > -Durl='tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.tightEncodingEnabled=false&keepAlive=true&wireFormat.maxInactivityDuration=6&socketBufferSize=32768' > -Dsubject=TopicRouted.1 -Duser=admin -Dpassword=admin -Dmax=1 -Dtopic=true > -DsleepTime=0 -Dmax=1 -DmessageSize=5000 > This modified version of the script prints the number of messages per second > and prints it to the console. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5076) Pooled session creation blocks when maxActive is reached
[ https://issues.apache.org/jira/browse/AMQ-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-5076. -- Resolution: Fixed Fix Version/s: 5.10.0 Assignee: Christian Posta Fixed c3d8ca7..dc607bb > Pooled session creation blocks when maxActive is reached > > > Key: AMQ-5076 > URL: https://issues.apache.org/jira/browse/AMQ-5076 > Project: ActiveMQ > Issue Type: Improvement > Components: activemq-pool >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.10.0 > > > Pooled session creation blocks when maxActive is reached. This is > configurable to either block or thrown an exception. We should maybe expose > the config to the generic pool we use under the covers so it can be even more > fine tuned, or at least provide a way to set a timeout on the blocking > behavior so that threads don't sit and block forever. > See > http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html > > and > http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html#setMaxWait(long) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-3606) Features descriptor should define the namespace
[
https://issues.apache.org/jira/browse/AMQ-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914637#comment-13914637
]
Christoph Emmersberger commented on AMQ-3606:
-
Hi
it seems that this issue still exists with activemq-karaf version 5.9.0. See
the following WARN message:
org.apache.karaf.features.core - 3.0.0 | Old style feature file without
namespace found (URI:
mvn:org.apache.activemq/activemq-karaf/5.9.0/xml/features). This format is
deprecated and support for it will soon be removed
Could be removed, e.g. via:
{code}
http://karaf.apache.org/xmlns/features/v1.2.0";>
...
{code}
> Features descriptor should define the namespace
> ---
>
> Key: AMQ-3606
> URL: https://issues.apache.org/jira/browse/AMQ-3606
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Jean-Baptiste Onofré
>Assignee: Dejan Bosanac
> Fix For: 5.6.0
>
> Attachments: AMQ-3606.patch
>
>
> The future Karaf 3.0 version will validate the features XML. The namespace is
> now require.
> I'm gonna submit a patch to define it.
> On the other hand, I think that the features-2.1.xml file is no more
> required. I will provide another patch to remove it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (AMQ-5078) Typos in stomp/ProtocolConverter.java
[ https://issues.apache.org/jira/browse/AMQ-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5078. --- Resolution: Fixed > Typos in stomp/ProtocolConverter.java > - > > Key: AMQ-5078 > URL: https://issues.apache.org/jira/browse/AMQ-5078 > Project: ActiveMQ > Issue Type: Improvement > Components: stomp >Affects Versions: 5.9.0 >Reporter: Lionel Cons >Priority: Trivial > Fix For: 5.10.0 > > Attachments: ProtocolConverter.patch > > > There are two typos in > activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java > that are polluting my logs. I attach a patch to fix them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5078) Typos in stomp/ProtocolConverter.java
[ https://issues.apache.org/jira/browse/AMQ-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-5078: -- Component/s: stomp Priority: Trivial (was: Minor) Affects Version/s: 5.9.0 Fix Version/s: 5.10.0 Issue Type: Improvement (was: Bug) > Typos in stomp/ProtocolConverter.java > - > > Key: AMQ-5078 > URL: https://issues.apache.org/jira/browse/AMQ-5078 > Project: ActiveMQ > Issue Type: Improvement > Components: stomp >Affects Versions: 5.9.0 >Reporter: Lionel Cons >Priority: Trivial > Fix For: 5.10.0 > > Attachments: ProtocolConverter.patch > > > There are two typos in > activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java > that are polluting my logs. I attach a patch to fix them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5078) Typos in stomp/ProtocolConverter.java
[ https://issues.apache.org/jira/browse/AMQ-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lionel Cons updated AMQ-5078: - Attachment: ProtocolConverter.patch > Typos in stomp/ProtocolConverter.java > - > > Key: AMQ-5078 > URL: https://issues.apache.org/jira/browse/AMQ-5078 > Project: ActiveMQ > Issue Type: Bug >Reporter: Lionel Cons >Priority: Minor > Attachments: ProtocolConverter.patch > > > There are two typos in > activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java > that are polluting my logs. I attach a patch to fix them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5078) Typos in stomp/ProtocolConverter.java
Lionel Cons created AMQ-5078: Summary: Typos in stomp/ProtocolConverter.java Key: AMQ-5078 URL: https://issues.apache.org/jira/browse/AMQ-5078 Project: ActiveMQ Issue Type: Bug Reporter: Lionel Cons Priority: Minor There are two typos in activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java that are polluting my logs. I attach a patch to fix them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
