Re: Shared File System Master Slave with OCFS
James Strachan wrote: Thanks for the heads up! :) I guess we could make the locking strategy pluggable we could have some implementation call the fcntl locking. e.g. maybe using Jtux http://www.basepath.com/aup/jtux/ Even though one could achieve this, I don't know what the benefit would be. It only shifts the responsibility down. At least the user would want a broker that is dependent on one or more brokers. Each of those brokers shouldn't be dependent on each other for locking, data, or anything else. I can appreciate that some people assume that shared data is available, but shared data is just as easily corrupted, locked, or unavailable. Essentially, when you find a single responsibility and divide it, it probably shouldn't converge somewhere down the line. This current pattern is most likely unusable for any HA situation. -- Christopher G. Stach II
Re: Shared File System Master Slave with OCFS
Christopher G. Stach II wrote: James Strachan wrote: Thanks for the heads up! :) I guess we could make the locking strategy pluggable we could have some implementation call the fcntl locking. e.g. maybe using Jtux http://www.basepath.com/aup/jtux/ Even though one could achieve this, I don't know what the benefit would be. It only shifts the responsibility down. At least the user would want a broker that is dependent on one or more brokers. Each of those brokers shouldn't be dependent on each other for locking, data, or anything else. I can appreciate that some people assume that shared data is available, but shared data is just as easily corrupted, locked, or unavailable. Essentially, when you find a single responsibility and divide it, it probably shouldn't converge somewhere down the line. This current pattern is most likely unusable for any HA situation. Wow. That sounded kind of snotty. :) I meant client that is dependent, too. -- Christopher G. Stach II
Re: Shared File System Master Slave with OCFS
James Strachan wrote: On 5/18/07, James Strachan [EMAIL PROTECTED] wrote: On 5/17/07, felipera [EMAIL PROTECTED] wrote: Hi everyone, I am trying to setup two MQ Servers (4.1.1), sharing the same data directory (I tried Derby and Kaha), on top of OCFS, but the locking doesn't seem to be working. It works fine when both MQs are running on the same server (still using OCFS). I see the second MQ waiting for the lock to be released (Journal is locked... waiting 10 seconds for the journal to be unlocked.). That's why I am not sure if it's a OCFS issue. But when I run each MQ in separate boxes (still sharing the same data directory using OCFS) it doesn't work, they both start successfully. This is the OCFS you're talking about right? http://en.wikipedia.org/wiki/OCFS2 Actually OCFS2 seems more like a real distributed file system for general purpose use; the OCFS looks more specifically for using to host oracle data tables. Am wondering how good the file locking is on OCFS? Certainly its clear the mutex file locking from Java isn't supported on OCFS. OCFS2 properly supports POSIX locking semantics with fcntl. lockf and flock aren't supported yet. If that's what the JVM uses under the covers, you're out of luck. If this is about OCFS and not OCFS2, I'm really sorry. :) -- Christopher G. Stach II
Re: Ports internally used by active Mq
Suchitha Koneru (sukoneru) wrote: Hello Active Mq Users , Our application currently uses active mq 4.0.1 version. We use an embedded broker along with durable subscribers and topic publishers. Active MQ also uses ports internally which are not configurable, these ports are randomly allocated. For these ports ,Does active mq take into account that if the port which it needs to use is already occupied , will it try allocating a different port ? Please let me know, we need this information because when our application is on the production machine , we do not have a control as to which ports are available. thanks, Suchitha If you're talking about random local ports like the ones used for JMX (RMI), the OS selects them. You can't bind two sockets to the same address-port pair. If it was the case that something didn't check if a port was already in use, and it was, it wouldn't even work. -- Christopher G. Stach II
Re: Ports internally used by active Mq
Christopher G. Stach II wrote: Suchitha Koneru (sukoneru) wrote: Hello Active Mq Users , Our application currently uses active mq 4.0.1 version. We use an embedded broker along with durable subscribers and topic publishers. Active MQ also uses ports internally which are not configurable, these ports are randomly allocated. For these ports ,Does active mq take into account that if the port which it needs to use is already occupied , will it try allocating a different port ? Please let me know, we need this information because when our application is on the production machine , we do not have a control as to which ports are available. thanks, Suchitha If you're talking about random local ports like the ones used for JMX (RMI), the OS selects them. You can't bind two sockets to the same address-port pair. If it was the case that something didn't check if a port was already in use, and it was, it wouldn't even work. Nerd disclaimer: It's sometimes possible. :) -- Christopher G. Stach II
Re: Monitoring Slave broker
Simon Wistow wrote: I have a pure master-slave set up and my sysadmins are trying to set up monitoring. One of the ways they're monitoring is to check to see if port 61616 is open. Obviously this works with the master but the slave naturally doesn't respond. Do you have any ideas of how to check if the slave is up and running bar grepping the process table? I see that in 4.2 I could check port 8161 but we're still running 4.01 at the moment. Thanks, Simon Use JMX. -- Christopher G. Stach II
Re: what's the meaning of transportConnector and networkConnector ?
hyqgod wrote: i want to ask another questions: what's the meaning of discover this TransportConnector using multicast. . How and why does a broker need to discover another brokers using multicast protocol ? Gaurav Hariani wrote: From what I understand - Transport Connector: An end point which clients (or other brokers) can connect to. This is what you use as the connection URI in clients. Network Connector: A remote end point at another broker, which this broker will connect to. You can certainly replace 'localhost' with an IP address in the uri's -- for Transport Connectors this IP will have to be that of the host. e.g. you could have a TransportConnector accepting connections on a specific IP address (useful for multi-honed hosts) or one TransportConnector for each network interface your host has. For Network Connector you WILL replace 'localhost' with the remote host's name/IP address (unless you are running multiple brokers on the same host) DiscoveryURI - is to allow other brokers to discover this TransportConnector using multicast. hyqgod wrote: i 'm a new guy of ActiveMQ, now i'm reading XML deployment descriptor for configurating the ActiveMQ Message Broker. when i reached some text below: transportConnectors transportConnector name=openwire uri=tcp://localhost:61616 discoveryUri=multicast://default/ transportConnector name=ssl uri=ssl://localhost:61617/ transportConnector name=stomp uri=stomp://localhost:61613/ transportConnector name=xmpp uri=xmpp://localhost:61222/ /transportConnectors networkConnectors networkConnector name=default-nc uri=multicast://default/ networkConnector name=host1 and host2 uri=static://(tcp://host1:61616,tcp://host2:61616) failover=true/ /networkConnectors i can't understand what are the meanings of transportConnector and networkConnectors object, i tried to find the explanations from api-docs,but got nothing. could anyone can help me to explain these or give me some useful links? thanks very much! By the way, i doubt whether i can replace the localhost with another ip address? and what does discoveryUri means? http://activemq.apache.org/using-activemq.html -- Christopher G. Stach II
Re: Problems with VM transport
Adrian Co wrote: Yeah. tcp would refer to an external broker. Can you post the complete stack trace? BTW, can you try using broker.useJmx=false instead of just useJmx=false? Is the exception occu [EMAIL PROTECTED] wrote: Suchitha, Thanks for your help. I thought a URL of the form tcp://host... refers to an external broker, not an embedded one? Am I mistaken? I need to run the broker within the servlet container VM, not as a separate process. ``tcp'' can refer to _any_ broker, local or remote, that has a TCP transportConnector. If you run a vm broker in one webapp and expect another webapp to talk to it, you just might run into classloader problems. -- Christopher G. Stach II
Re: Problems with VM transport
[EMAIL PROTECTED] wrote: Hello... I have a couple of basic questions on ActiveMQ. I would appreciate any hits as I am stuck. I am using ActiveMQ 4.1 with JDK6. 1) When I use an embedded broker with vm transport (vm://localhost) the instantiation of my Spring SimpleMessageListenerContainer always fails with a JournalLockedException. What does this exception mean exactly? I understand this has something to do with persistance of message (since that is on by default). While I do not care to enable persistance and would like to turn it off, I would still like to understand what causes this exception: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DmmStartupMessageListener' defined in class path resource [contexts/bus/DmsStandardSubscriptions.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/apache/activeio/journal/active/JournalLockedException Caused by: java.lang.NoClassDefFoundError: org/apache/activeio/journal/active/JournalLockedException at org.apache.activemq.broker.BrokerService.createPersistenceFactory(BrokerService.java:1328) at org.apache.activemq.broker.BrokerService.getPersistenceFactory(BrokerService.java:544) at org.apache.activemq.broker.BrokerService.createPersistenceAdapter(BrokerService.java:1320) at org.apache.activemq.broker.BrokerService.getPersistenceAdapter(BrokerService.java:631) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1250) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1209) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:508) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:394) at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:113) at org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:52) at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:43) at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:77) at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:227) 2) Which jarfile contains the exception class org/apache/activeio/journal/active/JournalLockedException? 3) How do I use an embedded broker without persistance? The URL vm://localhost?persistant=false fails with an exception that says that theoption is illegal. 4) Once the broker is up, could I dynamically (programmatically) change the broker URL by augmenting the broker URL with a failover URL as follows? Startup: vm://localhost During runtime (after an event): failover(vm://localhost,tcp://remote:61616) Would modifying the broker URL of the connection factory cause problems? Thanks, /U This was kind of like watching a retarded kid fall down, and laughing... but three times in a row. Thanks. -- Christopher G. Stach II
Re: [Spam: 5.0] JMX Remote Access - Necessary ports
Juergen Mayrbaeurl wrote: Can you tell me something about the mentioned ways to get it worked? How does this work with RMI based EJB access? We don't have this problems with our JBoss servers. Kind regards Juergen http://issues.apache.org/activemq/browse/AMQ-1164 So, if you configure amq:managementContext rmiServerPort=, you end up with ports 1099 and that you would need to allow through the firewall. This is a bad idea. To fix this, don't open any ports on the firewall, tunnel ports 1099 and over SSH (1099:localhost:1099, :localhost:), start AMQ with -Djava.rmi.server.hostname=localhost, and connect with jconsole or whatever to localhost:1099. -- Christopher G. Stach II
Re: [Spam: 5.0] JMX Remote Access - Necessary ports
James Strachan wrote: On 3/8/07, Juergen Mayrbaeurl [EMAIL PROTECTED] wrote: What kind of JMX connector do I need for JManage? Can I use the RMI connector? Does JManage have to run on the same machine? Yeah, I think what Paul meant was to use RMI/JMX locally on the box then use the HTTP over the firewall to avoid having to tinker with both the JMX and RMI ports on your firewall. Otherwise make sure the RMI and the JMX connector ports are accessible through the firewall AMQ has a nice feature to bind the registry to a fixed port, but you can't enable any form of security on it. There's an open issue for this. You may just want to use SSH tunneling. -- Christopher G. Stach II
Re: Too many open files exception on broker
GaryG wrote: A co-worker here recommended upping the open file limit before I bring up the Broker JVM with these commands: -- ulimit -u unlimited ulimit -n 9 ulimit -s unlimited --- Which, I'll try shortly, but what I don't understand, is why would AMQ even be in such a state in the first place? Is there a bug with this too many open files issue? Is there another fix that is recommended? It's normal *nix resource limits. Just like the nohup thing, this really doesn't have anything to do with AMQ specifically. -- Christopher G. Stach II
Re: [Spam: 5.0] Expired Message Listener
manav wrote: Any ideas if this is fixed in any latest development build? I see a 4.2-SNAPSHOT and 4.2-incubator-snapshot under the 'source' link.. Not sure how 'incubator' build is different from the other one.. but am ready to try anything if it is fixed... Christopher G. Stach II wrote: I don't think expiration works in 4.1. -- Christopher G. Stach II I don't know if it is, but I think it's supposed to be. Let us know. :) -- Christopher G. Stach II
Re: [Spam: 5.0] Expired Message Listener
Vadim Pesochinsky wrote: You do not need to set it up, if queue does not exist when you connect to it, it will be created. I think by default the sharedDeadLetterStrategy is used, i.e. all expired messages from all queues go to the same ActiveMQ.DLQ queue. The individual strategy has this nice feature where it changes the JMSDestination to the DLQ's name. If shared does that, you won't know (by headers) what the original destination was. Then you can't use the JMX message selectors to requeue, etc. -- Christopher G. Stach II
Re: [Spam: 5.0] Expired Message Listener
manav wrote: Could someone pease respond back to the posted question? We are holding off a release as we cannot get (do not know how to get) message expiry to work in 4.1. This is critical to a big company using AMQ. Any immediate help / suggestion is appreciated. Manav I don't think expiration works in 4.1. -- Christopher G. Stach II
Re: ActiveMQ Broker dying
GaryG wrote: I am not using a Java Service Wrapper. Not sure what that is. Then how do you know that you aren't using it? I am using the broker as installed, just from command line, with the only modifications to the config file being the turning off of the shutdown hook, adding jmx, and commenting out the network connector stuff. Literally it's pretty much out of the box. ps -auwwx | grep wrapper cat `find / -type f -name wrapper.log` :) This is absolutely critical for our system, I don't understand why the broker just dies, and this has been happening regularly! I know it's not due to a rogue control-C being pressed (had those issues too and fixed them by disabling the shutdown hook) If it's absolutely critical, maybe you should hire someone to help you. I don't think it's just dying, but I have seen the service wrapper kill a broker for a lot of reasons. It also restarts the broker when it dies or the wrapper kills it, but I have also seen the wrapper fail to restart the broker. -- Christopher G. Stach II
Re: ActiveMQ Broker dying
GaryG wrote: Here's the tail-end of the activemq.log -- 2007-02-20 02:53:13,685 [eckpoint Worker] DEBUG DefaultJDBCAdapter - Deleted 0 old message(s). 2007-02-20 02:53:13,685 [eckpoint Worker] DEBUG JDBCPersistenceAdapter - Cleanup done. 2007-02-20 02:53:13,685 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint done. 2007-02-20 02:54:42,690 [34.186.82:35922] DEBUG UsageManager - Memory usage change. from: 11, to: 12 2007-02-20 02:58:43,669 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint started. 2007-02-20 02:58:43,680 [eckpoint Worker] DEBUG JDBCPersistenceAdapter - Cleaning up old messages. 2007-02-20 02:58:43,680 [eckpoint Worker] DEBUG DefaultJDBCAdapter - Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER) 2007-02-20 02:58:43,681 [eckpoint Worker] DEBUG DefaultJDBCAdapter - Deleted 0 old message(s). 2007-02-20 02:58:43,682 [eckpoint Worker] DEBUG JDBCPersistenceAdapter - Cleanup done. 2007-02-20 02:58:43,682 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint done. 2007-02-20 03:01:03,878 [main ] INFO BrokerService - ActiveMQ Message Broker (amqDev2, ID:atla-dev-aic2.mss.iss.net-38984-1171932491732-1:0) is shutting down 2007-02-20 03:01:03,879 [main ] INFO NetworkConnector - Network Connector default-nc Stopped Following your posted commands, I looked for the Java Service Wrapper running, and did not see any such process. I couldn't find the wrapper.log either. I'm assuming from that it's not running. I'm not aware of us ever using this tool. Our OS is RedHat Linux. We're running java version 1.5.0_07 _Gary AMQ 4.1.0 comes with Java Service Wrapper in the standard binary package. It would restart the broker for you. Until you figure out why it's stopping, that may be your best bet. That's definitely a somewhat organized shutdown. It's not just a JVM crash, which wouldn't log anything. (The most stable VM I've run AMQ in was Sun 1.5.0_09, so you may want to try that just in case.) Turn logging up and see where the shutdown init is coming from? (Might want to obfuscate those iss.nets. :)) -- Christopher G. Stach II
Re: ActiveMQ Broker dying
GaryG wrote: 1. Is JSW enabled by default in AMQ? Like I said, I don't see it running. The wrapper init script (named activemq) and config (named wrapper.conf) live in apache-activemq-4.1.0-incubator/bin/linux/. 3. By turning on the logging, are you talking about log4j for the AMQ? I've already got it set to debug, what other debug options do you need turned on? Yeah, log4j. Trace, maybe? Also, it seems that when I run the broker as /opt/activemq-4.1.0/bin/activemq without putting it into background with , it's been staying up since this morning. I don't see how that'd be different from running it in the background. Just an observation. When you put the broker into the background with , does that session stay open? Could the terminal's disonnection and HUP signal be killing it on you? Is it recommended to always run it embedded, and not put it in background as a command line process? Totally depends on your requirements. Both are recommended, I think. :) -- Christopher G. Stach II
Re: ActiveMQ Broker dying
GaryG wrote: I'm getting the feeling that my session terminal closing does have something to do with it. So, would you recommend using that JSW service? You said in the previous posts that it has problems, so should I even other trying? Our Linux guys are telling me to run it like this instead: nohup /opt/activemq-4.1.0/bin/activemq /dev/null Perhaps that should be put in your documentation as the only way to make sure the broker can be ran from command line as a background process without dying. Try either configuring JSW (better idea) or running your broker like this: nohup blahblah/bin/activemq start /dev/null 21 The JSW packaged with 4.1.0 is out of date and the example wrapper.conf is pretty broken. There are some web pages about fixing the JSW config, though. Google for org.tanukisoftware.wrapper.WrapperStartStopApp and activemq, maybe. -- Christopher G. Stach II
Re: ActiveMQ Broker dying
Christopher G. Stach II wrote: GaryG wrote: I'm getting the feeling that my session terminal closing does have something to do with it. So, would you recommend using that JSW service? You said in the previous posts that it has problems, so should I even other trying? Our Linux guys are telling me to run it like this instead: nohup /opt/activemq-4.1.0/bin/activemq /dev/null Perhaps that should be put in your documentation as the only way to make sure the broker can be ran from command line as a background process without dying. Try either configuring JSW (better idea) or running your broker like this: nohup blahblah/bin/activemq start /dev/null 21 The JSW packaged with 4.1.0 is out of date and the example wrapper.conf is pretty broken. There are some web pages about fixing the JSW config, though. Google for org.tanukisoftware.wrapper.WrapperStartStopApp and activemq, maybe. Drrr. Somehow, I didn't realize you had already typed the nohup thing. It's Mardi Gras. :) -- Christopher G. Stach II
Re: ActiveMQ Broker dying
GaryG wrote: I'm having a problem with my Broker shutting down for no reason. I'm running it with mostly default configuration from command line: /opt/activemq-4.1.0/bin/activemq /dev/null My config file sets up the broker with Derby persistence adapter. broker brokerName=amqDev2 useShutdownHook=false useJmx=true xmlns=http://activemq.org/config/1.0; Here are the last few logs out of activemq.log: --- 2007-02-20 00:11:18,003 [eckpoint Worker] DEBUG DefaultJDBCAdapter - Deleted 0 old message(s). 2007-02-20 00:11:18,003 [eckpoint Worker] DEBUG JDBCPersistenceAdapter - Cleanup done. 2007-02-20 00:11:18,003 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint done. 2007-02-20 00:14:47,336 [34.186.85:58648] DEBUG UsageManager - Memory usage change. from: 19, to: 20 2007-02-20 00:16:17,991 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint started. 2007-02-20 00:16:18,001 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint done. 2007-02-20 00:18:03,432 [main ] INFO BrokerService - ActiveMQ Message Broker (amqDev2, ID:atla-dev-aic2.mss.iss.net-38553-1171920526058-1:0) is shutting down 2007-02-20 00:18:03,434 [main ] INFO NetworkConnector - Network Connector default-nc Stopped Everything is working fine, messages are going across, then all of a sudden, for no reason broker shuts down. This is driving me nuts, as this problem has been happening for a while now, and I cannot figure out why. Any suggestion is appreciated! Are you using Java Service Wrapper? What does the wrapper log say? -- Christopher G. Stach II
Re: Can't set prefetch size!
magic.moose wrote: I tried that. Resource Adapter simply references connectionFactory: bean id=broker class=org.apache.activemq.xbean.BrokerFactoryBean depends-on=serverConnector property name=config value=classpath:broker.xml / property name=start value=true / /bean bean id=connectionFactory class=org.apache.activemq.ActiveMQConnectionFactory singleton=true property name=brokerURL value=vm://localhost/ /bean bean id=jmsResourceAdapter class=org.apache.activemq.ra.ActiveMQResourceAdapter property name=connectionFactory ref=connectionFactory / /bean where broker.xml: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://activemq.org/config/1.0; broker name=localhost persistent=false useJmx=true transportConnectors transportConnector uri=vm://localhost / /transportConnectors memoryManager usageManager id=memory-manager limit=20 MB / /memoryManager destinationPolicy policyMappolicyEntries policyEntry queue=testQueue dispatchPolicy roundRobinDispatchPolicy/ /dispatchPolicy pendingMessageLimitStrategy constantPendingMessageLimitStrategy limit=0/ /pendingMessageLimitStrategy /policyEntry /policyEntries/policyMap /destinationPolicy /broker /beans queuePrefetch property of resource adapter doesnt help. and it really is 10 ! it not only that it behaves like it is 10. thats what i can see via jmx. Try this: bean id=connectionFactory class=org.apache.activemq.ActiveMQConnectionFactory singleton=true property name=brokerURL value=vm://localhost?jms.redeliveryPolicy.allPrefetchValues=1/ /bean -- Christopher G. Stach II