Re: java.io.EOFException when ActiveMQ starts
My activemq.xml is configured like below. -- View this message in context: http://activemq.2283324.n4.nabble.com/java-io-EOFException-when-ActiveMQ-starts-tp4717598p4717709.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: activeMQ fails on NetApp switch
Can you please forward the details of how you're mounting the NetApp exports? Please include all all NFS parameters. Thanks, Paul On Thursday, October 6, 2016, fgwrote: > Hi, > > We have 5 managed virtual servers with managed NetApp SAN Storage at our > hoster. On every server an instance of ActiveMQ 5.12.0 is running. We use > the NetApp as shared file system with kahaDB and mount a folder with NFSv4. > This is our persistenceAdapter configuration: > > > lockKeepAlivePeriod="5000"> > > > > > > > Whenever our hoster test the NetApp redundancy and switch between the > NetApp > Nodes our ActiveMQ crashes. The following error appears in the log of > server1: > > I2016-09-19 12:27:26,100 INFO [ActiveMQ Lock KeepAlive Timer] > org.apache.activemq.util.LockFile: Lock file /mnt/apache/queue/lock, > locked > at Wed Sep 14 18:49:26 CEST 2016, has been modified at Mon Sep 19 12:27:21 > CEST 2016 > I2016-09-19 12:27:26,101 ERROR [ActiveMQ Lock KeepAlive Timer] > org.apache.activemq.broker.LockableServiceSupport: osm1Broker, no longer > able to keep the exclusive lock so giving up being a master > > Server5 took the Handle but after 12 Minutes the same logs appears. I think > there was another switch, but we don't get the info from our hoster. After > that activeMQ stops working. More and more messages are stored in queue. > After a complete restart, everythin works as expected. > > Is there any misconfiguration or tips? > I thougt about switching to CephFS or GlusterFS to stay away from managed > NetApp. Are there any experiences? > > > > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/activeMQ-fails-on-NetApp-switch-tp4717558.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- Thanks, Paul
Re: ActiveMQ NMS and Failure Recovery
The first thing I notice is that you haven't actually enabled failover. The connection URI should be based on this: activemq:failover:tcp://hostname:61616 The inclusion of failover: is important. Beyond that, if you break inside of a debugger, you most likely will be disconnected by the broker. So I'm not sure what you are asking. Do you want to survive breakpoints in a debugger, or do you want normal failover in production? On Sun, Oct 9, 2016, 9:00 AM magmasystemswrote: > Hello all, > > As we prepare to ship our new product that uses ActiveMQ NMS heavily, I am > trying to harden the code against possible failures. One of the things that > our developers have noticed (and others in this group may have noticed) is > that it is common to get NMSExceptions when you are stopped at a breakpoint > for a while in Visual Studio. The connection is lost, and often times, we > need to restart our services. > > Our typical connection string is this: > > > > activemq:tcp://myserver:61616?transport.useInactivityMonitor=falseamp;keepAlive=true > > I have a few questions: > > 1) Let's say that we have a few cached consumers. If a connection faulted, > and we need to open a new connection, I assume that we also need to create > new sessions and therefore, create new consumers and producers? Or is there > any way to take an existing session and associate it with a new connection? > > 2) What are the best patterns for failure recovery, especially when a > connection goes down because of a "keep-alive" violation? Do we need to > only > create a new connection? Do we need to recreate all sessions? Do we need to > recreate all consumers and producers? > > 3) Are there any other parameters that you feel that I should add to my > URI? > I see that there are parameters like: > > wireFormat.maxInactivityDuration (set to either a large number or to -1 ... > people have tried both) > maxInactivityDurationInitalDelay > > Thanks very much for any advice. > > -marc > > > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
ActiveMQ NMS and Failure Recovery
Hello all, As we prepare to ship our new product that uses ActiveMQ NMS heavily, I am trying to harden the code against possible failures. One of the things that our developers have noticed (and others in this group may have noticed) is that it is common to get NMSExceptions when you are stopped at a breakpoint for a while in Visual Studio. The connection is lost, and often times, we need to restart our services. Our typical connection string is this: activemq:tcp://myserver:61616?transport.useInactivityMonitor=falseamp;keepAlive=true I have a few questions: 1) Let's say that we have a few cached consumers. If a connection faulted, and we need to open a new connection, I assume that we also need to create new sessions and therefore, create new consumers and producers? Or is there any way to take an existing session and associate it with a new connection? 2) What are the best patterns for failure recovery, especially when a connection goes down because of a "keep-alive" violation? Do we need to only create a new connection? Do we need to recreate all sessions? Do we need to recreate all consumers and producers? 3) Are there any other parameters that you feel that I should add to my URI? I see that there are parameters like: wireFormat.maxInactivityDuration (set to either a large number or to -1 ... people have tried both) maxInactivityDurationInitalDelay Thanks very much for any advice. -marc -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
random udp port being opened
Hello, On both the client and the server (where broker is started) I am seeing an udp port being opened. The port number is random each time. I am not figuring out why this udp port is being opened or which static code is opening it. Wondering whether anyone can throw some light on why this udp port is being opened and where it is used and if possible how to disable it. If some plugin is opening it, how to disable it. Really appreciate the comments. I am using broker in embedded mode and the clients to connect to it from either same system on different systems. I am using 5.13.1 version of ActiveMQ on Linux Centos systems 7.x. Code snippet for broker start part, if it helps... broker = new SslBrokerService(); broker.setPersistent(true); broker.setBrokerName("dobby"); broker.setUseJmx(false); broker.setPlugins(new BrokerPlugin[] { new IPAuthenticationPlugin(), new StatisticsBrokerPlugin() }); broker.setEnableStatistics(true); broker.addSslConnector("ssl://10.1.1.10:61617",.) broker.start(); netstat -tulpen |grep 31197 # 31197 is the java pid which starts broker udp0 0 0.0.0.0:48924 0.0.0.0:* 4981236777544 31197/java The client side url is similar, ssl or failover Again, I see a udp port being opened here. Thanks. Chandra -- View this message in context: http://activemq.2283324.n4.nabble.com/random-udp-port-being-opened-tp4717699.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Virtual topics, custom prefix limitations
This blog post ( http://workingwithqueues.blogspot.com/2012/05/activemq-virtual-topics-or-virtual.html?m=1) seems to indicate that you can. Please let us know if it works. On Oct 4, 2016 8:31 AM, "Devlin"wrote: > When customizing virtual topic consumer "prefix", can I use wildcards? > > I know this works: > > > > > > ..not sure if this /would/ work: > > > > > > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
Re: ActiveMQ ReplicatedLevelDB corruption
This is the first I'd heard of a replicated KahaDB implementation. I'd heard of multi-KahaDB (mKahaDB), but that's multiple KahaDB databases on a single broker (split by destination) rather than replicated. Maybe someone else can provide more info... On Oct 5, 2016 1:51 AM, "mlange"wrote: > thanks for providing a good idea of what to expect; yet I think it's good > to > be aware of this. > I did notice upon searching that there has been done some work to get > Kahadb > replicating; is that completely abandoned or is it still something that > might get implemented (in a somewhat near future) I think it's a great idea > to have the database replicating, to reduce the added complexity of shared > storage (which may itself fail, so needs to have it's own fault tolerance) > > I'll explore what other options are available and work well. > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/ActiveMQ-ReplicatedLevelDB-corruption-tp4716831p4717517.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >