http://permalink.gmane.org/gmane.comp.java.activemq.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.activemq.user/34125 <pre>you can set a specific statement string via the setter on statements element. eg: peek for lockCreateStatement in the schema and have a look at http://fusesource.com/docs/broker/5.4/persistence/JDBC-Customize.html On 25 May 2012 15:17, Alex Hooper &lt;ahooper-pN6YAzbKI0RWk0Htik3J/w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Gary Tully 2012-05-25T20:18:06 http://permalink.gmane.org/gmane.comp.java.activemq.user/34124 <pre>Gary Tully uttered: Ah, right, the keepAlive is for extant locks, not for keeping-alive connections that are waiting for a lock. Which is, in hindsight, exactly what the name suggests. I cannot see a way to validate the jdbc connection while the slave is blocked waiting for a response to its SELECT FOR UPDATE as the validation can only be done on idle connections and the connection is not idle, it is actively waiting for a response to its query. Even removeAbandoned won't touch it, as . . . it hasn't been abandoned. Yes, sorry -- I should have done this earlier. But it's so long since I've coded Java that I assumed finding the right bit would take me a geological age. Looking at that nice while loop, it occurs to me that another approach that would work, would be to alter the SQL used to grab the lock to so that it won't wait indefinitely, eg: SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE WAIT 300 From looking at http://activemq.apache.org/schema/core/activemq-core-5.5.0.xsd, I cannot see a way</pre> Alex Hooper 2012-05-25T14:17:42 http://permalink.gmane.org/gmane.comp.java.activemq.user/34123 <pre>On Thu, 2012-05-24 at 08:14 -0700, gauche wrote: One possiblity here is that this isn't working because the JMSXUserID value isn't returned in the ActiveMQConnectionMetaData's getJMSXPropertyNames which could be why the mapper isn't catching that property. That is of course if it uses that method to catch the vendor specific property names. </pre> Timothy Bish 2012-05-25T13:55:06 http://permalink.gmane.org/gmane.comp.java.activemq.user/34122 <pre>the keepAlive kicks in after the start() has successfully obtained the lock, so a slave should just block, but a master should check the lock status every period. By default it does an update using the connection that has a pending transaction. It may be that that update has no need to hit the server till a commit... not sure. May depend on the driver. But it should be sufficient to validate the jdbc connection. Have peek at the source: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/DefaultDatabaseLocker.java?view=markup On 25 May 2012 13:36, Alex Hooper &lt;ahooper-pN6YAzbKI0RWk0Htik3J/w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Gary Tully 2012-05-25T13:17:03 http://permalink.gmane.org/gmane.comp.java.activemq.user/34121 <pre>Gary Tully uttered: [snip] [snip] How exactly does the lock keepalive mechanism work? I'm explicitly set it in the xml config now: &lt;jdbcPersistenceAdapter brokerName="prod-s01" dataDirectory="${activemq.base}/data" dataSource="#oracle-ds" useDatabaseLock="true" lockKeepAlivePeriod="10"&gt; &lt;statements&gt; &lt;statements stringIdDataType="VARCHAR(128)" /&gt; &lt;/statements&gt; &lt;/jdbcPersistenceAdapter&gt; But once the instance has started and issued its initial lock-requesting query, there is no further TCP activity at all. Maybe I've misunderstood the intent of this function; that's far from unlikely. Alex. </pre> Alex Hooper 2012-05-25T12:36:09 http://permalink.gmane.org/gmane.comp.java.activemq.user/34120 <pre>Hi, I've got an ActiveMQ 5.3.0 broker running in one JVM. &lt;transportConnectors&gt; &lt;transportConnector name="openwire" uri="tcp://localhost:19616"/&gt; &lt;/transportConnectors&gt; Another application (different JVM but currently on the same machine) connects to that broker to receive messages from a single queue through a MessageListener: failover://(tcp://localhost:19616?keepAlive=true)?startupMaxReconnectAttempts=5 The message frequency is rather low (5-500 per hour) and can drop to zero over multiple hours (during the night). Every now and then, the MessageListener simply doesn't get any more messages and we have to restart the application for a reconnect despite the failover protocol (as seen above). We've tried various connection URI parameters but so far, the issue keeps popping up every few weeks. I somehow doubt it has to do with some timeout because, yesterday, it happened during the day during normal business, not in the night after hours of inactivity. When the problem happe</pre> Jeremias Maerki 2012-05-25T10:23:54 http://permalink.gmane.org/gmane.comp.java.activemq.user/34119 <pre>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&lt;String, Object&gt; headers = headerMapper.toHeaders(jmsMessage); Message&lt;?&gt; requestMessage = (result instanceof Message&lt;?&gt;) ? MessageBuilder.fromMessage((Message&lt;?&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</pre> gauche 2012-05-24T15:14:09 http://permalink.gmane.org/gmane.comp.java.activemq.user/34118 <pre>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 &lt;ricardo.sanz-lhvGifhGsuv1P9xLtpHBDw&lt; at &gt;public.gmane.org&gt; wrote: </pre> Gary Tully 2012-05-24T14:48:10 http://permalink.gmane.org/gmane.comp.java.activemq.user/34117 <pre>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: &lt;bean id="oracle-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"&gt; &lt;property name="driverClassName" value="oracle.jdbc.driver.OracleDriver" /&gt; &lt;property name="url" value="jdbc:oracle:thin:&lt; at &gt;oracle:1521:bmj01" /&gt; &lt;property name="username" value="activemq" /&gt; &lt;property name="password" value="activemq" /&gt; &lt;property name="maxActive" value="200" /&gt; &lt;property name="maxIdle" value="5" /&gt; &lt;property name="testWhileIdle" value="true" /&gt; &lt;property name="timeBetweenEvictionRunsMillis" value="30000" /&gt; &lt;property name="validationQuery" value="SELECT 1 FROM DUAL" /&gt; &lt;property name="poolPreparedStatements" value="true" /&gt; &lt;/bean&gt; I have yet to try 'removeAbandoned' as that d</pre> Alex Hooper 2012-05-24T13:56:47 http://permalink.gmane.org/gmane.comp.java.activemq.user/34116 <pre>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 &lt;acmmailing-UraKqTVSIh7k1uMJSBkQmQ&lt; at &gt;public.gmane.org&gt; wrote: </pre> Gary Tully 2012-05-24T13:53:50 http://permalink.gmane.org/gmane.comp.java.activemq.user/34115 <pre>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 gro</pre> Arjen van der Meijden 2012-05-24T13:12:35 http://permalink.gmane.org/gmane.comp.java.activemq.user/34114 <pre>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.22833</pre> RickSnz 2012-05-24T11:38:05 http://permalink.gmane.org/gmane.comp.java.activemq.user/34113 <pre>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 connect</pre> Gary Tully 2012-05-24T11:15:09 http://permalink.gmane.org/gmane.comp.java.activemq.user/34112 <pre>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. </pre> Alex Hooper 2012-05-24T10:45:31 http://permalink.gmane.org/gmane.comp.java.activemq.user/34111 <pre>Hello, I'm trying to use MQTT protocol between ActiveMQ broker and JMS client. Broker is started with MQTT transport: &lt;transportConnector name="mqtt" uri="mqtt://0.0.0.0:61616"/&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.ru</pre> Dmytro Pishchukhin 2012-05-24T10:29:26 http://permalink.gmane.org/gmane.comp.java.activemq.user/34110 <pre>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 &lt;johnboyer99-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Gary Tully 2012-05-24T10:01:09 http://permalink.gmane.org/gmane.comp.java.activemq.user/34109 <pre>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. </pre> mickhayes 2012-05-24T08:09:14 http://permalink.gmane.org/gmane.comp.java.activemq.user/34108 <pre>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 publ</pre> mickhayes 2012-05-24T07:42:26 http://permalink.gmane.org/gmane.comp.java.activemq.user/34107 <pre>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. </pre> Steve.V. 2012-05-23T20:59:06 http://permalink.gmane.org/gmane.comp.java.activemq.user/34106 <pre>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. </pre> johneboyer 2012-05-23T20:57:31 http://permalink.gmane.org/gmane.comp.java.activemq.user/34105 <pre>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 </pre> Steve.V. 2012-05-23T16:23:21 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.activemq.user