<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.java.activemq.user">
    <title>gmane.comp.java.activemq.user</title>
    <link>http://blog.gmane.org/gmane.comp.java.activemq.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34119"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34118"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34117"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34116"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34115"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34114"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34113"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34112"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34111"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34110"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34109"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34108"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34107"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34106"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34105"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34104"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34103"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34102"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34101"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.activemq.user/34100"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34119">
    <title>Re: JMSXUserID propagation not working</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34119</link>
    <description>&lt;pre&gt;OK, I've found out what's causing this and would greatly appreciate some
advice for moving forward. I'm not even sure that this is an AMQ issue
anymore...

The internal framework I depend on uses spring-integration-jms to wrap the
JMS message. The code in question looks like this:

Map&amp;lt;String, Object&amp;gt; headers = headerMapper.toHeaders(jmsMessage);
Message&amp;lt;?&amp;gt; requestMessage = (result instanceof Message&amp;lt;?&amp;gt;) ?
MessageBuilder.fromMessage((Message&amp;lt;?&amp;gt;)
result).copyHeaders(headers).build() : 
MessageBuilder.withPayload(result).copyHeaders(headers).build();

jmsMessage in my case is an instance of ActiveMQTextMessage. It has the
userID correctly set, and the "JMSXUserID" property is not present in its
property map. This is also the case when I run the relevant unit tests in
the AMQ code base, so I assume it's all working correctly at this point.

However, the header mapper being used is DefaultJmsHeaderMapper, which is
part of spring-integration-jms. This mapper does not set JMSXUserID, and it
kind of can't without taking a dependency on AMQ. Since JmsMessage does not
have a getUserID() method, it would need to cast the message to AMQ's
Message type first.

And thus, the user ID just kind of gets lost.

I'm interested to hear whether this is an issue with AMQ,
spring-integration, neither, or both.

Meanwhile, I'm at least attempting to get this internal framework to use my
own header mapper, but it looks tedious at best.

Thanks

--
View this message in context: http://activemq.2283324.n4.nabble.com/JMSXUserID-propagation-not-working-tp4644649p4652689.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>gauche</dc:creator>
    <dc:date>2012-05-24T15:14:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34118">
    <title>Re: NetworkConnectors and prefetch</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34118</link>
    <description>&lt;pre&gt;the problem here is that the network bridge 'proxy' consumer is faster
than the local consumers.
you can use decreaseNetworkConsumerPriority=true to slow down the
network bridge but even this will not give you the desired effect with
prefetch=1, but it will help.

The other alternative is to build your own dispatch filter of a
network consumer and have it rate limit what messages are consumed.
There is an example in
org.apache.activemq.network.ConditionalNetworkBridgeFilterFactory
which is like what you need except that it only limits messages that
are being redirected back to their origin.

If  decreaseNetworkConsumerPriority does not work, peek at:
org.apache.activemq.usecases.TwoBrokerQueueClientsReconnectTest#applyRateLimitNetworkFilter

On 24 May 2012 12:38, RickSnz &amp;lt;ricardo.sanz-lhvGifhGsuv1P9xLtpHBDw&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-24T14:48:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34117">
    <title>Re: change strategy for determining failure of primary in JBDC-backed setup</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34117</link>
    <description>&lt;pre&gt;Gary Tully uttered:

Ah, excellent; I'd not managed to tease that information out of the docs.


Yes, that might make sense, thanks. Will need further pondering...


I had already identified the commons pool options that might help and have 
configured thusly:

   &amp;lt;bean id="oracle-ds"
   class="org.apache.commons.dbcp.BasicDataSource"
   destroy-method="close"&amp;gt;
     &amp;lt;property name="driverClassName"
     value="oracle.jdbc.driver.OracleDriver" /&amp;gt;
     &amp;lt;property name="url" value="jdbc:oracle:thin:&amp;lt; at &amp;gt;oracle:1521:bmj01" /&amp;gt;
     &amp;lt;property name="username" value="activemq" /&amp;gt;
     &amp;lt;property name="password" value="activemq" /&amp;gt;
     &amp;lt;property name="maxActive" value="200" /&amp;gt;
     &amp;lt;property name="maxIdle" value="5" /&amp;gt;
     &amp;lt;property name="testWhileIdle" value="true" /&amp;gt;
     &amp;lt;property name="timeBetweenEvictionRunsMillis" value="30000" /&amp;gt;
     &amp;lt;property name="validationQuery" value="SELECT 1 FROM DUAL" /&amp;gt;
     &amp;lt;property name="poolPreparedStatements" value="true" /&amp;gt;
   &amp;lt;/bean&amp;gt;


I have yet to try 'removeAbandoned' as that doesn't seem to be appropriate.

Interestingly, netstat on the slave activemq box shows an ESTABLISHED TCP 
connection to the oracle server, but the oracle server shows no socket in any 
state connected to the slave activemq. Which kind of explains why activemq isn't 
noticing the connection drop. So... maybe the 'removeAbaandoned' option is 
appropriate, as the connection is not getting cleared by the dbcp checks because 
the connection that has been used to issue the "SELECT * FROM ACTIVEMQ_LOCK FOR 
UPDATE" is deemed as being active and thus never checked.

More fundamentally, of course, I need to work out what's going wrong at the TCP 
level and sort that.

[snip]

Is that option configurable in the XML config?

Anyway, thanks, Gary, for a detailed and pertinent response. This has given me a 
few things to try.

Cheers,

Alex.


&lt;/pre&gt;</description>
    <dc:creator>Alex Hooper</dc:creator>
    <dc:date>2012-05-24T13:56:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34116">
    <title>Re: java.io.IOException: Too many open files (v5.4.2)</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34116</link>
    <description>&lt;pre&gt;Sorry, my bad. You are correct. It is just the server side 'socket'
close that is async, not the tear down of broker state relating to a
connection, so there is no client impact.

asyncSync close really just means that there is a thread pool handling
close rather than the transport thread, so the transport thread can
get on with being reused if socket.close blocks for a bit.

On 24 May 2012 14:12, Arjen van der Meijden &amp;lt;acmmailing-UraKqTVSIh7k1uMJSBkQmQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-24T13:53:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34115">
    <title>Re: java.io.IOException: Too many open files (v5.4.2)</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34115</link>
    <description>&lt;pre&gt;Are you sure the client even notices this?

 From our experience, I'm fairly certain that only the server side of 
the connections where still open when we ran into this IOException.

I.e. isn't the correctly and completely closed (in Stomp-communication 
terms from the client perspective) connection put into a queue to later 
completely remove all connection information, close the server side of 
the socket, etc?

Actually, if there would be a last communication towards the client, I'd 
expect the non-asynchronous method of closing to be quicker per single 
client rather than adding a delay. Especially under load. Queueing for 
asynchronous processing normally suggests some form of unknown and 
highly variable latency.
I can see two advantages of asynchronous closing. Firstly, it'll reduce 
time a thread spends on a single connection by pushing part of that work 
into a backend processing thread. Which in the end should result in a 
reduced amount of threads being active at any time.
And secondly it can group several close/cleanup-operations in one go and 
thus reduce the overhead per cleanup.

But reduced delay for the close-confirmation towards a client wouldn't 
be anything I'd expect from a asynchronous background operation.

So while synchronous closing may increase the load for the broker by 
pushing this work into the communication threads and increasing the 
relative overhead for each cleanup/close. It shouldn't really be a 
disadvantage to the client side. Or am I missing a step?

Best regards,

Arjen

On 24-5-2012 12:01 Gary Tully wrote:

&lt;/pre&gt;</description>
    <dc:creator>Arjen van der Meijden</dc:creator>
    <dc:date>2012-05-24T13:12:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34114">
    <title>NetworkConnectors and prefetch</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34114</link>
    <description>&lt;pre&gt;Hello,

We are using a network of brokers but it's giving us some problems with load
balancing. Most of the messages are being delivered to the remote broker
instead of being shared between the network connector and the broker's
consumer. If a broker has 5 consumers and 1 network connector, and receives
50 messages, it processes 5-10 in its consumers and the rest outside

We are using prefetch = 1 for the consumers, so we set prefetchSize=1 for
the network connector. We have tried both with and without
conduitSubscriptions. The only configuration that have worked was setting a
high prefetch in consumers and network connector, but that was only for
testing purpose, as we cant modify the consumer's prefetch size.

So we need to know if there's any way to make it work with prefetch = 1 in
the consumers. The expected behaviour in the case explained before would be
processing 25 messages in the broker's consumers and send 25 to the network
connector.

Thanks

--
View this message in context: http://activemq.2283324.n4.nabble.com/NetworkConnectors-and-prefetch-tp4652677.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>RickSnz</dc:creator>
    <dc:date>2012-05-24T11:38:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34113">
    <title>Re: change strategy for determining failure of primary in JBDC-backed setup</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34113</link>
    <description>&lt;pre&gt;You would need to write some code, but the locker implementation can
be easily overridden.
The interface is: org.apache.activemq.store.jdbc.DatabaseLocker

It acquires the lock in start which typically blocks till it can get a
lock and there are periodic calls to keepalive once the lock is
obtained.

and it is set via xml config on the JDBCPersistenceAdapter via
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter#setDatabaseLocker

A lease type strategy may make sense, where a read to determine if
there is an existing owner is followed by a poll when the lease is
expired or an update to start a new lease if none exists. The owner of
the lease needs to renew before it expires and that interval needs to
be configurable to allow timely reclamation.

In the event that the connection drops, if it is recreated before the
lease expires, the master/slave state is retained. If the lease has
expired, a master and slave will contend for the lock to be the new
master.

In your setup, it is odd that the dropped connection does not cause
the lock keepAlive to fail and the broker to terminate. It should,
unless there are tcp level options that need to kick in to see the
half close. Or some connection pool config that can pick up on the
failure, there are some validate options on commons jdbc pool that
could help there.

This has cropped up before, in the case of a ha jdbc back end
(clusterd) and there is a drop in the connection while the cluster
fails over due to say routine maintenance.

Currently there is no good solution to this because the default locker
will terminate on the dropped connection. A lease will help here, but
when the lease expires there is still the problem of picking a new
master. Not sure there is an easy solution to that.

Hopefully the above will help, but start with determining why in your
current setup, the lock keepalive is not triggering for you when the
connection is dropped because that is a little odd. unless you have
the org.apache.activemq.store.jdbc.JDBCPersistenceAdapter#setLockKeepAlivePeriod
= 0.


On 24 May 2012 11:45, Alex Hooper &amp;lt;ahooper-pN6YAzbKI0RWk0Htik3J/w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-24T11:15:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34112">
    <title>change strategy for determining failure of primary in JBDC-backed setup</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34112</link>
    <description>&lt;pre&gt;Hi,

We are running activemq 5.5.1 in an active/passive failover configuration with 
JDBC Persistence to an Oracle backend. The default strategy for determining 
whether the current master has failed is for the secondary server to attempt to 
get a lock on the database table, waiting indefinitely for the lock to be granted.

This is not working (at least in our context) as, after a relatively short time 
in operation (a handful of hours at most) the connection to Oracle is dropped. 
Activemq doesn't notice this, so the secondary sits there happily waiting for a 
lock it can now never get and, in the event of a failure, won't serve any 
clients as it is not a master.

Is there some way to change the decision mechanism to, eg, a polling strategy? 
Or can anyone suggest another resolution to this problem?

Alex.
&lt;/pre&gt;</description>
    <dc:creator>Alex Hooper</dc:creator>
    <dc:date>2012-05-24T10:45:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34111">
    <title>Unable to connect/send messages with MQTT transport from JMS client</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34111</link>
    <description>&lt;pre&gt;Hello,

I'm trying to use MQTT protocol between ActiveMQ broker and JMS client.

Broker is started with MQTT transport: &amp;lt;transportConnector name="mqtt"
uri="mqtt://0.0.0.0:61616"/&amp;gt;
One queue and one topic are configured.

1. For testing I use HermesJMS tool. I've configured the tool with
MQTT jars (from /apache-activemq-5.6.0/lib/optional folder) and
brockerURL: mqtt://localhost:61616
When I try to open connection (just open an queue tab-panel) I receive
such exception:

javax.jms.JMSException: java.io.EOFException
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1362)
at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1466)
at org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:396)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:174)
        ...
at hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:250)
at org.apache.activemq.transport.mqtt.MQTTWireFormat.unmarshal(MQTTWireFormat.java:80)
at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:229)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:221)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:204)
... 1 more

Broker logs:
WARN | Transport Connection to: tcp://127.0.0.1:2442 failed:
org.apache.activemq.transport.InactivityIOException: Channel was
inactive for too (&amp;gt;30000) long: tcp://127.0.0.1:2442

2. I've tried to test with my small test client based on ActiveMQ
without any success.
2.1. with mqtt://localhost:61616
Logs:
2012-05-24 12:22:03.029 [FINE]
org.apache.activemq.transport.mqtt.MQTTProtocolConverter
onActiveMQCommand
Do not know how to process ActiveMQ Command ConnectionInfo {commandId
= 1, responseRequired = true, connectionId =
ID:BK5N00025814-8614-1337854948615-2:1, clientId =
ID:BK5N00025814-8614-1337854948615-1:1, clientIp = null, userName =
null, password = *****, brokerPath = null, brokerMasterConnector =
false, manageable = true, clientMaster = true, faultTolerant = false,
failoverReconnect = false}

2.2. with failover://(mqtt://localhost:61616) it always tries to
reconnect after approx. 30 seconds.

3. When I tried to send messages from MQTT client
(mqtt-client-1.2-uber.jar) - everything was fine.

Question:
Are there any tricks in configuration of MQTT protocol for ActiveMQ
JMS clients? I did find any information on the documentation page.

Thanks in advance.

Best regards,
Dmytro Pishchukhin

&lt;/pre&gt;</description>
    <dc:creator>Dmytro Pishchukhin</dc:creator>
    <dc:date>2012-05-24T10:29:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34110">
    <title>Re: java.io.IOException: Too many open files (v5.4.2)</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34110</link>
    <description>&lt;pre&gt;yes, closeAsync=false can help reduce the number of open sockets if
the broker is busy at the cost of delaying the close response to the
client, but you need to really ask your computer that question; in
other words, do an empirical test.

On 23 May 2012 21:57, johneboyer &amp;lt;johnboyer99-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-24T10:01:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34109">
    <title>Re: Is this right Apache forum?</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34109</link>
    <description>&lt;pre&gt;Apache *HTTPD *- the webserver - is an Apache Software Foundation (ASF)
project: http://httpd.apache.org/
Various support fora/mail lists are here: http://httpd.apache.org/lists.html

Is that what you are looking for? If not, read on...

Apache *ActiveMQ* - User discussion is right here on nabble.com

*Apache Software Foundation* -
http://www.apache.org/foundation/mailinglists.html 



-----
Michael Hayes B.Sc. (NUI), M.Sc. (DCU), SCSA SCNA 

--
View this message in context: http://activemq.2283324.n4.nabble.com/Is-this-right-Apache-forum-tp4651939p4652671.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>mickhayes</dc:creator>
    <dc:date>2012-05-24T08:09:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34108">
    <title>Re: CodeMaps updates for Active MQ</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34108</link>
    <description>&lt;pre&gt;Great. 
Look forward to trying it out. What I was trying to say was I like the
Atlassian approach to jira (we pay for licenses, whereas FOSS projects may
get a free license), and would be /more happy/ with an instance of a
facility such as yours being in the hands of the opensource projects, a la
jira. 

More feedback: 

While you're in there, a lines-of-code analysis overall, and on a class by
class basis would be good to see. We use ohloh.net (now owned by blackduck)
but we can't see the source code alongside, or get a detailed breakdown
apart from on a language basis. 
To have some code-counting alongside the source would be useful for me.
 
Finally, just in case, I should say that nabble broke your url when you
asterisked it:

http://activemq.2283324.n4.nabble.com/file/n4652670/No_such_project.jpg 

 - it should be http://www.codemaps.org/c/Apache_ActiveMQ

While most people - I guess - will notice and fix it, for *maximum success
of your project, you need to test (I mean verify) that everything you
publish works*, or you lose customers at every stage.

All the best,
Mick Hayes

-----
Michael Hayes B.Sc. (NUI), M.Sc. (DCU), SCSA SCNA 

--
View this message in context: http://activemq.2283324.n4.nabble.com/CodeMaps-updates-for-Active-MQ-tp4650879p4652670.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>mickhayes</dc:creator>
    <dc:date>2012-05-24T07:42:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34107">
    <title>Re: ActiveMQ 5.6, IllegalStateException, MessageServlet.java:368</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34107</link>
    <description>&lt;pre&gt;I believe that problem was caused by me specifying the wrong character
encoding.

-----
Stephen Vincent
--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-5-6-IllegalStateException-MessageServlet-java-368-tp4651797p4652135.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>Steve.V.</dc:creator>
    <dc:date>2012-05-23T20:59:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34106">
    <title>Re: java.io.IOException: Too many open files (v5.4.2)</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34106</link>
    <description>&lt;pre&gt;Thank you Gary very much for your suggestions!

Incidentally, we do have a lot of short lived STOMP producers. Should we
also set /transport.closeAsync=false/ as suggested by Arjen earlier?

Regards,

John Boyer

--
View this message in context: http://activemq.2283324.n4.nabble.com/java-io-IOException-Too-many-open-files-v5-4-2-tp4643701p4652133.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>johneboyer</dc:creator>
    <dc:date>2012-05-23T20:57:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34105">
    <title>ActiveMQ 5.6, IllegalStateException, MessageServlet.java:368</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34105</link>
    <description>&lt;pre&gt;I attempt to put a text message on a queue using HTTP.  The admin shows the
enqueued *and* dequeued counters both incremented by one.  The broker log
excerpt follows.  I must be doing something it doesn't like.  Any assistance
will be apreciated.  Thanks.


2012-05-23 12:09:56,040 | DEBUG | call servlet MessageServlet |
org.eclipse.jetty.servlet.ServletHandler | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,040 | DEBUG | destination uri=request |
org.apache.activemq.web.MessageServletSupport | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,040 | DEBUG | request (queue) |
org.apache.activemq.web.MessageServletSupport | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,040 | DEBUG | Sending message to: queue://request with
text: this is a test23MAY12:12:09:56 |
org.apache.activemq.web.MessageServlet | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,040 | DEBUG | localhost Message
ID:d22275-3380-1337789359310-3:1:1:1:1 sent to queue://request |
org.apache.activemq.broker.region.Queue | ActiveMQ Task-1

2012-05-23 12:09:56,040 | DEBUG | request toPageIn: 1, Inflight: 0,
pagedInMessages.size 0, enqueueCount: 1, dequeueCount: 0 |
org.apache.activemq.broker.region.Queue | BrokerService[localhost] Task-1

2012-05-23 12:09:56,040 | DEBUG | Async client internal exception occurred
with no exception listener registered: java.lang.IllegalStateException:
DISPATCHED,initial | org.apache.activemq.ActiveMQConnection | ActiveMQ
Session Task-1

java.lang.IllegalStateException: DISPATCHED,initial

at
org.eclipse.jetty.server.AsyncContinuation.dispatch(AsyncContinuation.java:403)

at
org.eclipse.jetty.server.AsyncContinuation.resume(AsyncContinuation.java:810)

at
org.apache.activemq.web.MessageServlet$Listener.onMessageAvailable(MessageServlet.java:368)

at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1320)

at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)

at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)

at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)

at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)

at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:619)

2012-05-23 12:09:56,055 | DEBUG | Sent! to destination: queue://request
message: ActiveMQTextMessage {commandId = 0, responseRequired = false,
messageId = ID:d22275-3380-1337789359310-3:1:1:1:1, originalDestination =
null, originalTransactionId = null, producerId = null, destination =
queue://request, transactionId = null, expiration = 0, timestamp =
1337789396040, arrival = 0, brokerInTime = 0, brokerOutTime = 0,
correlationId = null, replyTo = null, persistent = true, type = null,
priority = 5, groupID = null, groupSequence = 0, targetConsumerId = null,
compressed = false, userID = null, content = null, marshalledProperties =
null, dataStructure = null, redeliveryCounter = 0, size = 0, properties =
null, readOnlyProperties = false, readOnlyBody = false, droppable = false,
text = this is a test23MAY12:12:09:56} | org.apache.activemq.web.WebClient |
qtp32489992-25 - /demo/message/request?type=queue

2012-05-23 12:09:56,055 | DEBUG | scope null||/demo/message/request &amp;lt; at &amp;gt;
o.e.j.w.WebAppContext{/fileserver,file:/C:/apache-activemq-5.6.0/webapps/fileserver/}
| org.eclipse.jetty.server.handler.ContextHandler | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,055 | DEBUG | RESPONSE /demo/message/request  200 |
org.eclipse.jetty.server.Server | qtp32489992-25 -
/demo/message/request?type=queue

2012-05-23 12:09:56,055 | DEBUG | filled 0/0 |
org.eclipse.jetty.http.HttpParser | qtp32489992-25


-----
Stephen Vincent
--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-5-6-IllegalStateException-MessageServlet-java-368-tp4651797.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>Steve.V.</dc:creator>
    <dc:date>2012-05-23T16:23:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34104">
    <title>Re: CodeMaps updates for Active MQ</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34104</link>
    <description>&lt;pre&gt;Hey Michael,

Thanks for pointing out the bug - we are looking in it.

As for bringing what we are doing in-house - that is exactly our goal. We
have been discussing ways to do that, but have been advised that no one
would care about it unless we can show it being useful. So, hopefully, you
guys will like the idea, and give us feedback, so that we can make it
awesome. :-)

A lot of this work was done based on feedback from some of the ASF guys at
CamelOne (including Hiram, as well as Dan Kulp, Rob Davies, and Shane
Curcuru).


On Wed, May 23, 2012 at 3:38 AM, mickhayes &amp;lt;mickhayes-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Abhishek Rakshit</dc:creator>
    <dc:date>2012-05-23T14:55:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34103">
    <title>Re: ActiveMQ Plugin references</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34103</link>
    <description>&lt;pre&gt;It works !

Thank you very much !!!

--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Plugin-references-tp4651507p4651619.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>mandjeo</dc:creator>
    <dc:date>2012-05-23T13:50:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34102">
    <title>Re: ActiveMQ Plugin references</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34102</link>
    <description>&lt;pre&gt;you will need to peek at the code to be sure, but you may be able to use:
org.apache.activemq.broker.BrokerFilter#getAdaptor

called on the root broker, which can be returned by
org.apache.activemq.broker.BrokerService#getBroker

The issue is that there is a one way list between broker and filters,
so you need to start at the root broker
to be sure all brokers/filters will be traversed when looking for
another instance.

On 23 May 2012 13:15, mandjeo &amp;lt;mandjeo-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-23T12:57:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34101">
    <title>ActiveMQ Plugin references</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34101</link>
    <description>&lt;pre&gt;Hi everybody,

I am developing some plugins for ActiveMQ and because I have more than one
plugin in my configuration I would like to connect them, that is to have a
reference from the one to another. 

If you can help me with the configuration and some examples of how can I
achieve this.

So from one class that extends a BrokerFilter I want to have a reference to
another one that is also working as a plugin (also extends BrokerFilter).

Thanks...

--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Plugin-references-tp4651507.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>mandjeo</dc:creator>
    <dc:date>2012-05-23T12:15:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34100">
    <title>Re: ActiveMQ rar source?</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34100</link>
    <description>&lt;pre&gt;have a peek at:
http://repo1.maven.org/maven2/org/apache/activemq/activemq-ra/5.5.1/activemq-ra-5.5.1-sources.jar

the rar is just a wrapper (with ra.xml) around the implementation in activemq-ra


On 23 May 2012 09:30, Croo &amp;lt;peter.balog-IzeFyvvaP7pWk0Htik3J/w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Gary Tully</dc:creator>
    <dc:date>2012-05-23T10:44:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.activemq.user/34099">
    <title>Re: ActiveMQ and Jboss AS 7</title>
    <link>http://permalink.gmane.org/gmane.comp.java.activemq.user/34099</link>
    <description>&lt;pre&gt;Hi.
I am having this ERROR in my Jboss log.

14:26:21,366 ERROR [org.jboss.msc.service] (MSC service thread 1-3)
MSC00002: Invocation of listener
"org.jboss.as.connector.deployers.processors.ParsedRaDeploymentProcessor$1&amp;lt; at &amp;gt;e40293"
failed: java.lang.IllegalArgumentException: JBAS014809: A node is already
registered at '(deployment =&amp;gt; activemq.rar)'
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108)
[jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68)
[jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.as.controller.registry.AbstractResourceRegistration.registerOverrideModel(AbstractResourceRegistration.java:97)
[jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.as.connector.deployers.processors.ParsedRaDeploymentProcessor$1.transition(ParsedRaDeploymentProcessor.java:181)
[jboss-as-connector-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at
org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at
org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[rt.jar:1.6.0_23]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[rt.jar:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]

This may not be a issue to worry at all. But I want someone to clarify me
this. 
And also I have one more question. Since I got my application deployed it
may not be a problem. But how do we address the issue when the
application(which is spring based war) get deployed before the activemq gets
deployed and will not find the jndi its looking for.

So, is there a way to ensure that this active mq is deployed along with the
other components(I mean the default components like hornetq and other stuff
loads) during booting. 

If so or If not, How can we force this to get loaded during the server
booting. Please specify if any configurations need to be addressed to ensure
that. If we can get this booted before the applications, that would be the
awesomest thing. and we can ignore the above error as well, since its
registered anyways.

Thanks for your support and help in this regards.

Ram

--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-and-Jboss-AS-7-tp4649224p4651319.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>bondrk</dc:creator>
    <dc:date>2012-05-23T09:07:43</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.java.activemq.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.java.activemq.user</link>
  </textinput>
</rdf:RDF>

