This does not point to a config issue. This warning is expected sometimes on failover, but should not occur in normal uninterrupted processing. Do you have a test case that can easily reproduce on windows? If so, please raise a jira issue and attach it. this is 5.3.0, correct?
On 19 March 2010 17:56, Fred Moore <[email protected]> wrote: > Gary, All, > > with your hints we made some progress on this by creating an java explicit > broker configuration (available here http://pastebin.com/7rJjV93r, see > BrokerInit()) that we believe is equivalent to the original activemq.xml > (available here http://pastebin.com/e66HqEdi). > > The major problems we had on z/OS are now over, but somehow the > java explicit broker configuration is not 100% equivalent to the original > activemq.xml, in fact when we run a simple 1 producer + 1 consumer test we > observe a very very slow consumer and also this log message: > > 2010-03-19 18:30:26,057 [VMTransport] WARN Service .serviceException - > Async error occurred: javax.jms.JMSException: Unmatched acknowledege: > MessageAck {commandId = 212, responseRequired = false, ackType = 2, > consumerId = ID:MyBRK-4741-1269019793401-1:0:2:1, firstMessageId = > ID:MyBRK-4741-1269019793401-1:0:1:1:100, lastMessageId = > ID:MyBRK-4741-1269019793401-1:0:1:1:100, destination = queue://MyTest, > transactionId = TX:ID:MyBRK-4741-1269019793401-1:0:3, messageCount = 1}; > Could not find Message-ID ID:MyBRK-4741-1269019793401-1:0:1:1:100 in > dispatched-list (start of ack) > javax.jms.JMSException: Unmatched acknowledege: MessageAck {commandId = > 212, > responseRequired = false, ackType = 2, consumerId = > ID:MyBRK-4741-1269019793401-1:0:2:1, firstMessageId = > ID:MyBRK-4741-1269019793401-1:0:1:1:100, lastMessageId = > ID:MyBRK-4741-1269019793401-1:0:1:1:100, destination = queue://MyTest, > transactionId = TX:ID:MyBRK-4741-1269019793401-1:0:3, messageCount = 1}; > Could not find Message-ID ID:MyBRK-4741-1269019793401-1:0:1:1:100 in > dispatched-list (start of ack) > at > > org.apache.activemq.broker.region.PrefetchSubscription.assertAckMatchesDispatched(PrefetchSubscription.java:440) > at > > org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:208) > at > > org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:369) > at > > org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470) > at > > org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194) > at > org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74) > at > > org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:85) > at > > org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:449) > at org.apache.activemq.command.MessageAck.visit(MessageAck.java:205) > at > > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:297) > at > > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:175) > at > > org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109) > at > > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:205) > 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:651) > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) > at java.lang.Thread.run(Thread.java:595) > > FWIW we are able to reproduce this on ActiveMQ 5.3 on Windows as well (so > z/OS is now completely out of the picture). > > Does anyone know what we did wrong with the java explicit config? > Cheers, > F. > > > > > > > On Fri, Feb 5, 2010 at 10:01 AM, Gary Tully <[email protected]> wrote: > > > I don't know. But the persistence mechanisms will not be writing text, it > > will be binary data which should avoid encoding, no? > > > > Have a go and report back with the next problem and we will take if from > > there. > > > > On 5 February 2010 08:51, Fred Moore <[email protected]> wrote: > > > > > Hi Gary, > > > > > > thanks for your answer. > > > > > > > I guess you could run without xml configuration > > > > and set any non default values via code > > > > > > yes right, we thought about that, it forces us to hardcode stuff we > > > wouldn't > > > have hardocoded but it could be done, but... > > > > > > ...do you expect that the only issues about having an EBCDIC default > > > file.encoding are related to the initial parsing of activemq.xml or you > > > anticipate that other know problems are lurking out there (e.g. > > > KahaDB/persistence related)? > > > > > > Cheers, > > > F. > > > > > > > > > > > > On Thu, Feb 4, 2010 at 7:17 PM, Gary Tully <[email protected]> > wrote: > > > > > > > I guess you could run without xml configuration and set any non > default > > > > values via code... > > > > > > > > BrokerService broker = new BrokerService(); > > > > broker.addConnector("tcp://..."); > > > > etc. > > > > > > > > On 4 February 2010 15:21, Fred Moore <[email protected]> wrote: > > > > > > > > > Hi folks, > > > > > > > > > > we have an application hosting an embedded broker instance which > > needs > > > to > > > > > run on z/OS box. > > > > > > > > > > Unfortunately the application heavily relies on EBCDIC I/O, so > > passing > > > > > -Dfile.encoding=ISO8859-1 to the JVM (as suggested in > > > > > http://activemq.apache.org/zos.html is not viable). > > > > > > > > > > We several things without success, the most reasonable one seemed > to > > > be > > > > > converting activem.xml di EBCDIC and adding an xml prolog asserting > > > > > encoding=IBM-1047, but it did not work... here's the associated > nasty > > > > > exception (" @@@@@@@@@" is actually non printable stuff > > in > > > > the > > > > > real case): > > > > > > > > > > org.springframework.beans.factory.BeanCreationException: Error > > creating > > > > > bean > > > > > with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined > in > > > URL > > > > > [file:/home/USR930/sposagent/config/activemq.xml.EBCDIC]: Cannot > > create > > > > > inner bean '(inner bean)' of type > > > > > [org.apache.activemq.broker.region.policy.PolicyMap] while setting > > bean > > > > > property 'destinationPolicy'; nested exception is > > > > > org.springframework.beans.factory.BeanCreationException: Error > > creating > > > > > bean > > > > > with name '(inner bean)#2' defined in URL > > > > > [file:/home/USR930/sposagent/config/activemq.xml.EBCDIC]: Cannot > > create > > > > > inner bean 'policyEntry#1cde1cde' of type > > > > > [org.apache.activemq.broker.region.policy.PolicyEntry] while > setting > > > bean > > > > > property 'policyEntries' with key [0]; nested exception is > > > > > org.springframework.beans.factory.BeanCreationException: Error > > creating > > > > > bean > > > > > with name 'policyEntry#1cde1cde' defined in URL > > > > > [file:/home/USR930/sposagent/config/activemq.xml.EBCDIC]: Error > > setting > > > > > property values; nested exception is > > > > > org.springframework.beans.NotWritablePropertyException: Invalid > > > property > > > > > ' @@@@@@@@@' of bean class > > > > > [org.apache.activemq.broker.region.policy.PolicyEntry]: Bean > property > > > > > ' @@@@@@@@@ ' is not writable or has an > > invalid > > > > > setter method. Does the parameter type of the setter match the > return > > > > type > > > > > of the getter > > > > > > > > > > Can anyone help? > > > > > Cheers, > > > > > F. > > > > > > > > > > > > > > > > > > > > > -- > > > > http://blog.garytully.com > > > > > > > > Open Source Integration > > > > http://fusesource.com > > > > > > > > > > > > > > > -- > > http://blog.garytully.com > > > > Open Source Integration > > http://fusesource.com > > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
