[
https://issues.apache.org/activemq/browse/SM-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46928#action_46928
]
Ryan Moquin commented on SM-1666:
---------------------------------
Another interesting tidbit. So this example works on that 3.3-SNAPSHOT, but
not on the 3.3 release. If I switch the JMS provider endpoint to the old jms
provider endpoint and run the test again, the test.destination ends up with
1998 messages, 2 are missing. When I look back at the servicemix output, I see
it complain that one of the xml message I'm adding as content is invalid:
[Fatal Error] :1:70: The element type "testMessage1" must be terminated by the
matching end-tag "</testMessage1>".
But my message doesn't have a testMessage1 as part of it's tag, so obviously
the message it's complaining about was modified somehow. Should
servicemix-bean components always be synchronized? I never seemed to have this
problem before unless I was doing something that could be intensive.
This is how I'm constructing my message, and in my client output the messages
are all correct.
String message = "<testMessage>" + i + "</testMessage>";
When I ran the test a second and third time, it looks like all the messages
made it through without an error. It appears the new servicemix-jms endpoints
will cause the system to lock up because it doesn't return an acknowledgement?
With the old endpoints, they appear to spit out the error and drop the message,
so at least things don't hang that way. Also, I noticed that I was sending
blank messages to the jms provider in the attached sample, which apparently
used to work in the old 3.3 (it's not what I'm doing in my actual app), but
that causes errors in the newest 3.3 versions as well. I corrected the test
code and am reattaching it (it has the old provider endpoint added as well).
Should the servicemix-jms endpoint fail graceful when a problem occurs? If I
exit servicemix when the new end point is hanging, the console will scroll for
a minute or two with a ton of error output from the endpoint. I guess I'll
discontinue my use of the newest servicemix-jms enpoints until it's known why
they are problematic.
Here is a snippet of the log:
[Fatal Error] :-1:-1: Premature end of file.
[Fatal Error] :1:70: The element type "testMessage1" must be terminated by the
matching end-tag "</testMessage1>".
ERROR - JmsComponent - Error processing exchange InOnly[
id: ID:192.168.1.4-11d4ed3c406-13:0
status: Active
role: provider
service: {http://servicemix.apache.org/samples/bridge}jmstwo
endpoint: endpoint
in: Unable to display: org.xml.sax.SAXParseException: The element type
"testMessage1" must be terminated by the match
g end-tag "</testMessage1>".
]
com.ctc.wstx.exc.WstxParsingException: Unexpected close tag </testMessage>;
expected </testMessage1>.
at [row,col {unknown-source}]: [1,80]
at
com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:605)
at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:461)
at
com.ctc.wstx.sr.BasicStreamReader.reportWrongEndElem(BasicStreamReader.java:3256)
at
com.ctc.wstx.sr.BasicStreamReader.readEndElem(BasicStreamReader.java:3198)
> Either servicemix-bean or servicemix-jms do not function properly.
> ------------------------------------------------------------------
>
> Key: SM-1666
> URL: https://issues.apache.org/activemq/browse/SM-1666
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-bean, servicemix-jms
> Affects Versions: servicemix-bean-2008.01, servicemix-jms-2008.01, 3.3
> Environment: Windows XP, 4GB mem, jdk 1.6
> Reporter: Ryan Moquin
> Priority: Blocker
> Attachments: bridge-test.zip
>
>
> At some point during the 3.3 SNAPSHOT releases, our application stopped
> working. I did not have a chance to get a concrete case together to
> illustrate the problem until now. The test case is as follows (client sends
> 2000 JMS messages):
> Client JMS App -> JMS consumer -> servicemix-bean -> JMS provider
> The attached project works perfectly fine on a 3.3-SNAPSHOT release I have
> which appears to be from August 22nd. I've never been able to get this
> sequence to work since, it appears that the servicemix-bean SU will choke
> after a couple hundred messages and freeze up.
> When I run the described test on my August 22nd servicemix I will end up with
> 2000 messages having been queued and dequeued from the test.source topic and
> queued on the test.destination topic.
> When I run the described test on the 3.3 release, I will end up with 2000
> message enqueued and dispatched on the test.source topic, but only 576
> dequeued. It mentions the other 1474 are in flight.
> If I look at the threads, I see a bunch that are stuck waiting for an
> exchange (I'm guessing the servicemix-jms component never sends a reply?):
> Name: pool-flow.seda.servicemix-bean-thread-7
> State: WAITING on [EMAIL PROTECTED]
> Total blocked: 0 Total waited: 1
> Stack trace:
> java.lang.Object.wait(Native Method)
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.waitForExchange(DeliveryChannelImpl.java:709)
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:472)
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:442)
> org.apache.servicemix.client.DefaultServiceMixClient.sendSync(DefaultServiceMixClient.java:156)
> test.BeanImpl.onMessageExchange(BeanImpl.java:96)
> org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:226)
> - locked [EMAIL PROTECTED]
> org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:212)
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:600)
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:554)
> org.apache.servicemix.common.AsyncBaseLifeCycle.onMessageExchange(AsyncBaseLifeCycle.java:510)
> org.apache.servicemix.common.SyncLifeCycleWrapper.onMessageExchange(SyncLifeCycleWrapper.java:60)
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:620)
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:168)
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> java.lang.Thread.run(Thread.java:619)
> This seems to be a bug to me since it worked on that one 3.3-SNAPSHOT, but
> not on any since. The 3.3-SNAPSHOT I have is also before the renaming of
> components to 2008.01.
> I'll try a few other tests to see if I can narrow down any other cause since
> I would really like to get upgraded to the full release.
> Attached is a small project that will allow you to reproduce this issue, it's
> just a modification of the bridge sample with an extra SU in it. Here is all
> you need to do:
> 1. Build the attached project.
> 2. Deploy the built bridge-test-sa-3.3.zip
> 3. execute "java -jar test-jms-client-1.0.one-jar.jar" from the
> bridge-test/test-jms-client/target directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
