Re: Hung Producer
FYI: I am using AMQ broker version 5.8.0 -- View this message in context: http://activemq.2283324.n4.nabble.com/Hung-Producer-tp4678060p4678061.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Hung Producer
I am running a message burst load test but producer hangs with the following
exception.
Test specifics
1. Non persistent messages 4KB each
2. 50 queues temp.queue.{0..49}
3. Client JVM runs 50 Message producers (Runnables in a threadpool
containing 50 threads)
4. All 50 message producer share instance of JmsTemplate which uses
PooledConnectionFactory (pool size=50, producerWindowSize=1024000)
5. After 15 minutes into the test or lesser the producers hang
6. Broker seem to be functioning and don't see any exceptions in broker at
debug log level. I can post messages from web console and messages get
consumed just fine.
7. Queue policy
Issue seems to happens irrespective of whether producerFlowControl is true
or false.
Name: producerTaskExecutor-13
State: RUNNABLE
Total blocked: 16 Total waited: 418
Stack trace:
java.net.SocketOutputStream.socketWrite0(Native Method)
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
java.net.SocketOutputStream.write(SocketOutputStream.java:159)
org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)
java.io.DataOutputStream.flush(DataOutputStream.java:123)
org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:176)
org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:322)
org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:304)
org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:85)
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:104)
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1304)
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1298)
org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1782)
- locked java.lang.Object@3fe5bf34
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289)
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224)
org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:79)
- locked org.apache.activemq.ActiveMQMessageProducer@46c0fb2
org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:67)
org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:589)
org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:569)
org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:546)
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:466)
org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:543)
producer.ProducerTask.run(ProducerTask.java:43)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:744)
The test functions well when the pool size is 1 but throughput is not upto
the required capacity.
Any suggestions? Would appreciate any inputs.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Hung-Producer-tp4678060.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Apache Shiro integration status
This is now finished and ready to be incorporated into trunk! The patch attached to https://issues.apache.org/jira/browse/AMQ-3621 Can someone please apply this patch (instructions in the issue) and push the changes back to trunk ASAP? I want to eliminate any conflicts that would surface due to trunk changes over time. Thanks! -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Mon, Feb 17, 2014 at 4:53 PM, Les Hazlewood wrote: > Please excuse the double post, but I thought I'd do it just in case since > the other thread was about Apollo. > > Hi all, > > An update: > > My former repo at https://github.com/lhazlewood/ > activemq/tree/trunk/activemq-shiro is now out of date: I basically > created that repository before ActiveMQ moved to git. Now that ActiveMQ is > on git, I've picked up from where I left off there in a personal local > clone of the ActiveMQ git repo. > > Anyway, the good news is that I'm about to attach a patch for the final > Shiro integration, hopefully to be included in the 5.10 release. > > We've worked out pretty much all of the kinks, and have 100% test > coverage, with weeks of integration testing in multiple environments. > We're now using it in production at Stormpath, so I'm comfortable marking > the work as 'done' to be included in the main ActiveMQ branch. > > I'll attach the patch today asap! > > Best, > > Les > > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > > > On Tue, Jun 4, 2013 at 10:18 AM, Christian Posta < > christian.po...@gmail.com> wrote: > >> Awesome, Les, thanks! I will take a look tonight. >> >> >> On Mon, Jun 3, 2013 at 11:11 AM, Les Hazlewood wrote: >> >> > I made quite a bit of progress over the weekend. Here is the result >> > of the latest effort: >> > >> > https://github.com/lhazlewood/activemq/tree/trunk/activemq-shiro >> > >> > Change log is here: >> > >> > >> > >> https://github.com/lhazlewood/activemq/commit/be2100ea2c5a421cd21a4c3ae158c65e6e14490f >> > >> > It works as follows: >> > >> > The ShiroPlugin installs 2 BrokerFilters at the moment: >> > >> > - A SubjectFilter which is responsible for constructing and >> > associating a Subject instance with Connections. Downstream filters >> > perform actual security checks. >> > - An AuthenticationFilter (downstream from the SubjectFilter) that >> > enforces client authentication as necessary. It supports system and >> > anonymous connections as well if desired. >> > >> > I still have to create an AuthorizationFilter (that would be >> > downstream from the AuthenticationFilter) that would allow access >> > control checks (can you subscribe to a destination or not, etc). >> > >> > All of this code is tested with 100% class, method and line coverage. >> > >> > Comments, suggestions and feedback are most welcome. >> > >> > Cheers, >> > >> > -- >> > Les Hazlewood | @lhazlewood >> > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 >> > PMC Chair, Apache Shiro: http://shiro.apache.org >> > >> >> >> >> -- >> *Christian Posta* >> http://www.christianposta.com/blog >> twitter: @christianposta >> > >
[jira] [Updated] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[
https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Les Hazlewood updated AMQ-3621:
---
Attachment: AMQ-3621.git.patch
I'm proud to announce that, pending further review, this work is complete
(patch attached). This is a substantial security addition to ActiveMQ that I
hope others find useful!
Test coverage for all additions is at 100% class and 100% method coverage
(almost 100% line coverage too - just a minor branch that couldn't be hit via
test mocks). The plugin has been tested extensively in various network
environments and Stormpath is using it in production.
To apply the patch, assuming you've cloned
http://git-wip-us.apache.org/repos/asf/activemq.git:
{code}
git checkout trunk
# create a temporary branch to apply the patch:
git checkout -b apply-AMQ-3162-patch
# ensure no errors are reported (this won't modify source):
git apply --check AMQ-3162.patch
# if no errors, apply to the patch branch:
git am --signoff < AMQ-3162.patch
# merge the patch branch to trunk:
git checkout trunk
git merge apply-AMQ-3162-patch
# push the change back to the ASF git server:
git push
{code}
> Integrate Apache Shiro with ActiveMQ as "security solution"
> ---
>
> Key: AMQ-3621
> URL: https://issues.apache.org/jira/browse/AMQ-3621
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Cservenak, Tamas
>Assignee: Claus Ibsen
> Fix For: 5.10.0
>
> Attachments: AMQ-3621.git.patch
>
>
> Integrate Apache Shiro with ActiveMQ as "security solution".
> This would benefit for ActiveMQ to have support for a vast amount of already
> existing solution (Realm implementations) that are out there for Shiro.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQ-5061) MQTT Hierarchical Destination names may start with a leading '/', which must be ignored when mapping to ActiveMQ destination name
[ https://issues.apache.org/jira/browse/AMQ-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903670#comment-13903670 ] Dhiraj Bokde commented on AMQ-5061: --- Do not apply this patch right now. I am testing whether the assumption I started with is correct, i.e. whether the leading '/' is meant to be ignored or not. Upon reading the specification it is not very clear, so I am still investigating this. > MQTT Hierarchical Destination names may start with a leading '/', which must > be ignored when mapping to ActiveMQ destination name > - > > Key: AMQ-5061 > URL: https://issues.apache.org/jira/browse/AMQ-5061 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5061.patch > > > MQTT hierarchical destination names use the '/' character to separate levels. > The name may start with a '/', which indicates root level, so it must be > ignored when mapping to ActiveMQ destination names. This is required so that > both 'TopicA' and '/TopicA' map to the same ActiveMQ destination name > 'TopicA'. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Apache Shiro integration status
Please excuse the double post, but I thought I'd do it just in case since the other thread was about Apollo. Hi all, An update: My former repo at https://github.com/lhazlewood/ activemq/tree/trunk/activemq-shiro is now out of date: I basically created that repository before ActiveMQ moved to git. Now that ActiveMQ is on git, I've picked up from where I left off there in a personal local clone of the ActiveMQ git repo. Anyway, the good news is that I'm about to attach a patch for the final Shiro integration, hopefully to be included in the 5.10 release. We've worked out pretty much all of the kinks, and have 100% test coverage, with weeks of integration testing in multiple environments. We're now using it in production at Stormpath, so I'm comfortable marking the work as 'done' to be included in the main ActiveMQ branch. I'll attach the patch today asap! Best, Les -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Tue, Jun 4, 2013 at 10:18 AM, Christian Posta wrote: > Awesome, Les, thanks! I will take a look tonight. > > > On Mon, Jun 3, 2013 at 11:11 AM, Les Hazlewood wrote: > > > I made quite a bit of progress over the weekend. Here is the result > > of the latest effort: > > > > https://github.com/lhazlewood/activemq/tree/trunk/activemq-shiro > > > > Change log is here: > > > > > > > https://github.com/lhazlewood/activemq/commit/be2100ea2c5a421cd21a4c3ae158c65e6e14490f > > > > It works as follows: > > > > The ShiroPlugin installs 2 BrokerFilters at the moment: > > > > - A SubjectFilter which is responsible for constructing and > > associating a Subject instance with Connections. Downstream filters > > perform actual security checks. > > - An AuthenticationFilter (downstream from the SubjectFilter) that > > enforces client authentication as necessary. It supports system and > > anonymous connections as well if desired. > > > > I still have to create an AuthorizationFilter (that would be > > downstream from the AuthenticationFilter) that would allow access > > control checks (can you subscribe to a destination or not, etc). > > > > All of this code is tested with 100% class, method and line coverage. > > > > Comments, suggestions and feedback are most welcome. > > > > Cheers, > > > > -- > > Les Hazlewood | @lhazlewood > > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > > PMC Chair, Apache Shiro: http://shiro.apache.org > > > > > > -- > *Christian Posta* > http://www.christianposta.com/blog > twitter: @christianposta >
Re: Work on Apollo
Hi all, An update: My former repo at https://github.com/lhazlewood/ activemq/tree/trunk/activemq-shiro is now out of date: I basically created that repository before ActiveMQ moved to git. Now that ActiveMQ is on git, I've picked up from where I left off there in a personal local clone of the ActiveMQ git repo. Anyway, the good news is that I'm about to attach a patch for the final Shiro integration, hopefully to be included in the 5.10 release. We've worked out pretty much all of the kinks, and have 100% test coverage, with weeks of integration testing in multiple environments. We're now using it in production at Stormpath, so I'm comfortable marking the work as 'done' to be included in the main ActiveMQ branch. I'll attach the patch today asap! Best, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Mon, Feb 3, 2014 at 12:26 PM, vatsal12 wrote: > Hi Hiram, > > Is it possible to do JAAS authorization for apollo ? > Examples are only for Authentication. > > I can develop JAAS interface for Shiro. > > Thanks > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Work-on-Apollo-tp4676511p4677345.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. >
[jira] [Updated] (AMQ-5061) MQTT Hierarchical Destination names may start with a leading '/', which must be ignored when mapping to ActiveMQ destination name
[ https://issues.apache.org/jira/browse/AMQ-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated AMQ-5061: -- Attachment: AMQ-5061.patch Patch for stripping leading '/' from MQTT topic names. Also includes unit tests for some other patches I submitted previously. > MQTT Hierarchical Destination names may start with a leading '/', which must > be ignored when mapping to ActiveMQ destination name > - > > Key: AMQ-5061 > URL: https://issues.apache.org/jira/browse/AMQ-5061 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5061.patch > > > MQTT hierarchical destination names use the '/' character to separate levels. > The name may start with a '/', which indicates root level, so it must be > ignored when mapping to ActiveMQ destination names. This is required so that > both 'TopicA' and '/TopicA' map to the same ActiveMQ destination name > 'TopicA'. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5061) MQTT Hierarchical Destination names may start with a leading '/', which must be ignored when mapping to ActiveMQ destination name
Dhiraj Bokde created AMQ-5061: - Summary: MQTT Hierarchical Destination names may start with a leading '/', which must be ignored when mapping to ActiveMQ destination name Key: AMQ-5061 URL: https://issues.apache.org/jira/browse/AMQ-5061 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.0 Reporter: Dhiraj Bokde Fix For: 5.10.0 MQTT hierarchical destination names use the '/' character to separate levels. The name may start with a '/', which indicates root level, so it must be ignored when mapping to ActiveMQ destination names. This is required so that both 'TopicA' and '/TopicA' map to the same ActiveMQ destination name 'TopicA'. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-5060) Upgrade to xstream 1.4.7
[ https://issues.apache.org/jira/browse/AMQ-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903459#comment-13903459 ] Jonathan Anstey commented on AMQ-5060: -- Waiting on current SMX bundles vote to close before pushing. > Upgrade to xstream 1.4.7 > > > Key: AMQ-5060 > URL: https://issues.apache.org/jira/browse/AMQ-5060 > Project: ActiveMQ > Issue Type: Task >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 5.10.0 > > > Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5060) Upgrade to xstream 1.4.7
Jonathan Anstey created AMQ-5060: Summary: Upgrade to xstream 1.4.7 Key: AMQ-5060 URL: https://issues.apache.org/jira/browse/AMQ-5060 Project: ActiveMQ Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 5.10.0 Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5059) The first packet from client to Broker MUST be a CONNECT packet, Broker MUST disconnect when UNSUBSCRIBE is the first packet
[ https://issues.apache.org/jira/browse/AMQ-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5059. --- Resolution: Fixed patch applied > The first packet from client to Broker MUST be a CONNECT packet, Broker MUST > disconnect when UNSUBSCRIBE is the first packet > > > Key: AMQ-5059 > URL: https://issues.apache.org/jira/browse/AMQ-5059 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5059.patch > > > The method MQTTProtocolConverter.onUnSubscribe(UNSUBSRIBE command) does not > call checkConnected() to check whether CONNECT has already been received or > not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5059) The first packet from client to Broker MUST be a CONNECT packet, Broker MUST disconnect when UNSUBSCRIBE is the first packet
[ https://issues.apache.org/jira/browse/AMQ-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated AMQ-5059: -- Attachment: AMQ-5059.patch Patch to check connection status on unsubscribe > The first packet from client to Broker MUST be a CONNECT packet, Broker MUST > disconnect when UNSUBSCRIBE is the first packet > > > Key: AMQ-5059 > URL: https://issues.apache.org/jira/browse/AMQ-5059 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5059.patch > > > The method MQTTProtocolConverter.onUnSubscribe(UNSUBSRIBE command) does not > call checkConnected() to check whether CONNECT has already been received or > not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5059) The first packet from client to Broker MUST be a CONNECT packet, Broker MUST disconnect when UNSUBSCRIBE is the first packet
Dhiraj Bokde created AMQ-5059: - Summary: The first packet from client to Broker MUST be a CONNECT packet, Broker MUST disconnect when UNSUBSCRIBE is the first packet Key: AMQ-5059 URL: https://issues.apache.org/jira/browse/AMQ-5059 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.0 Reporter: Dhiraj Bokde Fix For: 5.10.0 The method MQTTProtocolConverter.onUnSubscribe(UNSUBSRIBE command) does not call checkConnected() to check whether CONNECT has already been received or not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5058) Broker MUST respond with CONNACK with return code 0x02 for zero length client id and 0 cleansession
[ https://issues.apache.org/jira/browse/AMQ-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5058. --- Resolution: Fixed applied on trunk > Broker MUST respond with CONNACK with return code 0x02 for zero length client > id and 0 cleansession > --- > > Key: AMQ-5058 > URL: https://issues.apache.org/jira/browse/AMQ-5058 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5058.patch > > > The CONNECT.decode() method from mqtt-client had an issue which has been > fixed in https://github.com/fusesource/mqtt-client/pull/31 > Wit this fix MQTTProtocolConverter.onConnect() can now check for the > condition outlined below and return a CONNACK with return code 0x02. > From MQTT 3.1.1 draft specification > [MQTT-3.1.3-6] A Server MAY allow a Client to supply a ClientId that has a > length of zero bytes. > However if it does so the Server MUST treat this as a special case and assign > a > unique ClientId to that Client. It MUST then process the CONNECT packet as if > the Client had provided that unique ClientId. > [MQTT-3.1.3-7] If the Client supplies a zero-byte ClientId, the Client MUST > also set Clean > Session to 1. > [MQTT-3.1.3-8] If the Client supplies a zero-byte ClientId with Clean Session > set to 0, the Server > MUST respond to the CONNECT Packet with a CONNACK return code 0x02 > (Identifier rejected) and then close the Network Connection. > [MQTT-3.1.3-9] If the Server rejects the ClientId it MUST respond to the > CONNECT Packet with > a CONNACK return code 0x02 (Identifier rejected) and then close the Network > Connection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5058) Broker MUST respond with CONNACK with return code 0x02 for zero length client id and 0 cleansession
[ https://issues.apache.org/jira/browse/AMQ-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated AMQ-5058: -- Attachment: AMQ-5058.patch Patch for adding support for zero length client id > Broker MUST respond with CONNACK with return code 0x02 for zero length client > id and 0 cleansession > --- > > Key: AMQ-5058 > URL: https://issues.apache.org/jira/browse/AMQ-5058 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde > Fix For: 5.10.0 > > Attachments: AMQ-5058.patch > > > The CONNECT.decode() method from mqtt-client had an issue which has been > fixed in https://github.com/fusesource/mqtt-client/pull/31 > Wit this fix MQTTProtocolConverter.onConnect() can now check for the > condition outlined below and return a CONNACK with return code 0x02. > From MQTT 3.1.1 draft specification > [MQTT-3.1.3-6] A Server MAY allow a Client to supply a ClientId that has a > length of zero bytes. > However if it does so the Server MUST treat this as a special case and assign > a > unique ClientId to that Client. It MUST then process the CONNECT packet as if > the Client had provided that unique ClientId. > [MQTT-3.1.3-7] If the Client supplies a zero-byte ClientId, the Client MUST > also set Clean > Session to 1. > [MQTT-3.1.3-8] If the Client supplies a zero-byte ClientId with Clean Session > set to 0, the Server > MUST respond to the CONNECT Packet with a CONNACK return code 0x02 > (Identifier rejected) and then close the Network Connection. > [MQTT-3.1.3-9] If the Server rejects the ClientId it MUST respond to the > CONNECT Packet with > a CONNACK return code 0x02 (Identifier rejected) and then close the Network > Connection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5058) Broker MUST respond with CONNACK with return code 0x02 for zero length client id and 0 cleansession
Dhiraj Bokde created AMQ-5058: - Summary: Broker MUST respond with CONNACK with return code 0x02 for zero length client id and 0 cleansession Key: AMQ-5058 URL: https://issues.apache.org/jira/browse/AMQ-5058 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.0 Reporter: Dhiraj Bokde Fix For: 5.10.0 Attachments: AMQ-5058.patch The CONNECT.decode() method from mqtt-client had an issue which has been fixed in https://github.com/fusesource/mqtt-client/pull/31 Wit this fix MQTTProtocolConverter.onConnect() can now check for the condition outlined below and return a CONNACK with return code 0x02. >From MQTT 3.1.1 draft specification [MQTT-3.1.3-6] A Server MAY allow a Client to supply a ClientId that has a length of zero bytes. However if it does so the Server MUST treat this as a special case and assign a unique ClientId to that Client. It MUST then process the CONNECT packet as if the Client had provided that unique ClientId. [MQTT-3.1.3-7] If the Client supplies a zero-byte ClientId, the Client MUST also set Clean Session to 1. [MQTT-3.1.3-8] If the Client supplies a zero-byte ClientId with Clean Session set to 0, the Server MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection. [MQTT-3.1.3-9] If the Server rejects the ClientId it MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5057) JDBC datastore unable to process messages after exception
Kurt Roekle created AMQ-5057: Summary: JDBC datastore unable to process messages after exception Key: AMQ-5057 URL: https://issues.apache.org/jira/browse/AMQ-5057 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.9.0 Environment: RHEL, MySql 5.5, mysql connector 5.1.17 Reporter: Kurt Roekle When using the jdbcPersistenceAdapter and an exception is thrown in the store, then no further messages can be consumed until the broker is restarted. I our case we were trying to store a message that was larger than what max_allowed_packet was set to in mysql (though I would assume other types of exceptions might cause the same issue). Valid messages sent after the exception occurred were stored in the database, but did not show up in the UI and could not be consumed. After a restart of the broker, the messages showed up in the UI and were able to be consumed. 2014-02-14 13:29:28,978 | WARN | Commit failed: Packet for query is too large (105132838 > 25165824). You can change this value on the server by setting the max_allowed_packet' variable. | org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | ActiveMQ Transport: tcp:///192.168.101.223:60777@61616 java.sql.BatchUpdateException: Packet for query is too large (105132838 > 25165824). You can change this value on the server by setting the max_allowed_packet' variable. at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:2024) at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1449) at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297) at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297) at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297) at org.apache.activemq.store.jdbc.TransactionContext.executeBatch(TransactionContext.java:106) at org.apache.activemq.store.jdbc.TransactionContext.executeBatch(TransactionContext.java:84) at org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:171) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516) at org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:110) at org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:259) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:70) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:253) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:112) at org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:424) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:149) at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113) at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196) at java.lang.Thread.run(Thread.java:724) Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (105132838 > 25165824). You can change this value on the server by setting the max_allowed_packet' variable. at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3279) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1971) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:1976) ... 24 more -- This message was sent by Atlass
Re: AMQ Browser Pagination
Very cool Zak! Thanks again On Feb 12, 2014 10:02 AM, "Zakeria Hassan" wrote: > HI Ashwini, > > I'll work on this tonight. > > Thanks, > Zak > > > > On Tue, Feb 11, 2014 at 5:34 PM, Ashwini Kuntamukkala < > ashwin.kuntamukk...@scispike.com> wrote: > >> Thanks Zak >> I have posted my comments on >> https://issues.apache.org/jira/browse/AMQ-5024 >> >> Look forward to a pull request soon >> Thanks again >> Ashwin >> >> *This e-mail and replies and forwards are for the sole use of the >> above individual(s) or entities and may contain proprietary, privileged >> and/or highly confidential information. Unauthorized use is strictly >> prohibited.* >> >> >> From: Zakeria Hassan >> Date: Tuesday, February 11, 2014 11:49 AM >> To: Ashwini Kuntamukkala , < >> dev@activemq.apache.org> >> Subject: Re: AMQ Browser Pagination >> >> Hi Ashwini, >> >> This project as you know is a community driven project and I plan on >> sending in a pull request soon. However, there is a road map that is put in >> place currently and you can contact Daniel Kulp for more details about this >> roadmap. This is something that the community is discussing currently. I >> invite you to join this community and share any feedback on the design I >> created. Just to keep this conversation transparent I've CC'd the ActiveMQ >> community to get their input. >> >> I will be sending in a pull request very soon once I've tested the new >> updates to the console. >> >> Cheers, >> Zak >> @Prospect1010 >> " *Before software can be reusable it first has to be usable.* " >> --Ralph Johnson >> >> >> >> >> >> On Tue, Feb 11, 2014 at 11:50 AM, Ashwini Kuntamukkala < >> ashwin.kuntamukk...@scispike.com> wrote: >> >>> Zakeria Hassan >>> >>> Good work on the pagination effort on AMQ Browser. >>> Is this part of the AMQ source code or is it still experimental in your >>> GIT repo? >>> Please let me know as I would like to get that enhancement in AMQ 5.8.0 >>> At this point we are unable to upgrade so I'd like to back port your >>> changes to version 5.8.0 >>> Please let me know >>> Thank you, >>> >>> Ashwini Kuntamukkala >>> http://akuntamukkala.blogspot.com >>> @akuntamukkala >>> >>> >>> *This e-mail and replies and forwards are for the sole use of the >>> above individual(s) or entities and may contain proprietary, privileged >>> and/or highly confidential information. Unauthorized use is strictly >>> prohibited.* >>> >>> >> >
ActiveMQ CliendID usage
Hi, I'm making some test on a JBoss Fuse with activemq OSGi deployed. I'm trying to consume via REST API a queue that I've created, in this queue there are several message. Using SOAP UI I try to connect getting this error: The clientID header specified is invalid. Client sesion has not yet been established for it: Is it an error usually related to ActiveMQ? Thanks, Nicola -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-CliendID-usage-tp4677943.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Created] (AMQ-5056) Can't not use slash (/) in the queue destination name .
Sam Huang created AMQ-5056: -- Summary: Can't not use slash (/) in the queue destination name . Key: AMQ-5056 URL: https://issues.apache.org/jira/browse/AMQ-5056 Project: ActiveMQ Issue Type: Bug Components: AMQP Affects Versions: 5.3.0 Reporter: Sam Huang I want to create two queue,name as (/queue/myqueue and /queue/myqueue/myservice). But I found that when I send the message to the queue: "/queue/myqueue/myservice",it will send to the first queue "/queue/myqueue" incorrectly. Then I trace the code ,found that when the InialContext use the method "lookup(String destinationName)",it will return the destination name "/queue/myqueue" even I my arguement is " /queue/myqueue/myservice". It haven't this error if I use another queue name says"/queue/anotherqueue" -- This message was sent by Atlassian JIRA (v6.1.5#6160)
