Thanks for the quick reply. We will try to configure this property to 30 sec.
However form old Jira, it could be because of Memory issue. https://issues.apache.org/jira/browse/AMQ-2730 I will keep you updated. -Idris On Thu, Feb 12, 2015 at 12:12 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Idris, > > this JMSException comes from the wireFormat.maxInactivityDurationInitalDelay > which is too low by default (10 seconds) on the transportConnector. > > It's not necessary a deadlock due to the log4j JMSAppender. > > I will update the configuration to increase to 30 seconds on the > transportConnector. > > A while ago, I submitted patches about the ActiveMQ update and a more > flexible way to configure the embedded broker. > > I've resumed this work. > > Regards > JB > > > On 02/11/2015 07:36 PM, Idris Ali wrote: > >> Hi JB, >> >> Slightly off from this discussion, we recently upgraded ActiveMQ version >> to >> 5.9.1 from 5.4.3 to work with Falcon. >> >> With the default configs, however we see wire format negotiation timedout >> issue pretty often and the job fails. >> >> Failing Oozie Launcher, Main class >> [org.apache.oozie.action.hadoop.JavaMain], main() threw exception, >> javax.jms.JMSException: Wire format negotiation timeout: peer did not >> send his wire format. >> org.apache.oozie.action.hadoop.JavaMainException: >> javax.jms.JMSException: Wire format negotiation timeout: peer did not >> send his wire format. >> at org.apache.oozie.action.hadoop.JavaMain.run(JavaMain.java:60) >> at org.apache.oozie.action.hadoop.LauncherMain.run( >> LauncherMain.java:42) >> at org.apache.oozie.action.hadoop.JavaMain.main(JavaMain.java:37) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke( >> NativeMethodAccessorImpl.java:57) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.apache.oozie.action.hadoop.LauncherMapper.map( >> LauncherMapper.java:293) >> at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54) >> >> >> Initial investigation suggests something to do with Log4j deadlock. >> Please let me know if this is a known issue in 5.9.1 ? >> >> Thanks, >> -Idris >> >> >> >> On Wed, Feb 11, 2015 at 9:20 AM, Pallavi Rao <[email protected]> >> wrote: >> >> JB, >>> We are working on Falcon talking to ActiveMQ HA setup too. Our initial >>> hunch is that as long as the right URL (with fail over scheme) is >>> specified >>> in the configuration, startup properties or cluster definition, it should >>> work without any code changes. Plan to run a quick test soon. Will keep >>> you >>> posted. >>> >>> Regards, >>> Pallavi >>> On Feb 10, 2015 7:51 PM, "Jean-Baptiste Onofré" <[email protected]> wrote: >>> >>> Hi all, >>>> >>>> I'm working on the ActiveMQ update (to 5.10.1) and improvements on the >>>> broker (configuration flexibility, tuning, etc). >>>> >>>> I plan also to improve the support of some ActiveMQ features, >>>> especially: >>>> 1/ master/slave support with kahadb and JDBC locking backend >>>> 2/ network of brokers support to be able to have Falcon instances >>>> producing on one broker which can dispatch the messages (including >>>> >>> conduit >>> >>>> subscriptions support) to other brokers where Falcon instances can get >>>> >>> the >>> >>>> messages. >>>> >>>> I will send more details and patches very soon. >>>> >>>> Thanks, >>>> Regards >>>> JB >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>> -- >>> _____________________________________________________________ >>> The information contained in this communication is intended solely for >>> the >>> use of the individual or entity to whom it is addressed and others >>> authorized to receive it. It may contain confidential or legally >>> privileged >>> information. If you are not the intended recipient you are hereby >>> notified >>> that any disclosure, copying, distribution or taking any action in >>> reliance >>> on the contents of this information is strictly prohibited and may be >>> unlawful. If you have received this communication in error, please notify >>> us immediately by responding to this email and then delete it from your >>> system. The firm is neither liable for the proper and complete >>> transmission >>> of the information contained in this communication nor for any delay in >>> its >>> receipt. >>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
