You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Christian Graf <ch...@knapp.com> on 2009/06/22 10:53:18 UTC
Servicemix 3.3 SendSync hangs after one night in idle mode.
Hi,
the problem i have is that service mix starts hanging after a night of
inactivity. In the evening when we stooped sending messages everything
worked fine. In the morning when we came back and tried to send messages the
system hangs in the "sendSync" message.
The system looks like this:
Component A -> EIP Content Router -> Active MQ (Oracle) -> Component B
There is no Exception or something else. Except when we stop the server,
than there are a bunch of exceptions like the one below:
08:57:42,225 | ERROR | 828483 Client-Thread - /192.168.0.83:4519 |
TcpConsumerEndpoint | .bus.tcpbc.TcpConsumerEndpoint 352 | Schliesse
Socket (/192.168.0.83:4519)
javax.jbi.messaging.MessagingException: java.lang.InterruptedException
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:508)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:442)
at
org.apache.servicemix.common.EndpointDeliveryChannel.sendSync(EndpointDeliveryChannel.java:115)
at
org.apache.servicemix.common.endpoints.SimpleEndpoint.sendSync(SimpleEndpoint.java:70)
at
com.knapp.bus.tcpbc.TcpConsumerEndpoint.doCommunication(TcpConsumerEndpoint.java:259)
at
com.knapp.bus.tcpbc.TcpConsumerEndpoint.access$200(TcpConsumerEndpoint.java:58)
at
com.knapp.bus.tcpbc.TcpConsumerEndpoint$ClientCommunicationThread.run(TcpConsumerEndpoint.java:615)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.waitForExchange(DeliveryChannelImpl.java:709)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:472)
... 6 more
The messages are send sync using a in-only mep. I hope someone can help me
with this problem.
Btw. after a restart of the bus everything is working fine again.
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24143726.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Freeman Fang <fr...@gmail.com>.
Hi Christian,
Enlarge your thread pool[1] and set reasonable timeout for sendSync can
reduce the hang possibility.
Another solution is your bc should support message throttle, which means
shouldn't send too much(means more request than the threadpool size)
concurrent request to your se.
[1]http://servicemix.apache.org/thread-pools.html
Freeman
Christian Graf wrote:
> Hi,
>
> thanks for the reply. The problem is that i have to ensure that the message
> reaches the Active MQ "safely" and in the same order as received. This is
> ensured by using "sendSync". "send" is asynchronous and that's to unsafe for
> our needs. :( Is there any other possibility?
>
> Regards,
> Christian
>
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi,
i switched from Database persistence to File persistence and it had the same
behavior this morning as with the database. The jms component just "hang".
Can anyone help me? Is there any other component to queue and save messages?
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24404470.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi,
the problem still exists and i got the following exceptions when i stop the
servicemix (there are a lot of these entries inside the log file). I copied
one of them for you. The database i use is Oracle 9.2.0.5.0. If this does
not work with oracle, is it save to use the "file" persistence for jms?
07:39:18,316 | ERROR | ActiveMQ Cleanup Timer | DefaultDatabaseLocker |
ore.jdbc.DefaultDatabaseLocker 109 | Failed to update database lock:
java.sql.SQLException: Io exception: Connection reset by peer: socket write
error
java.sql.SQLException: Io exception: Connection reset by peer: socket write
error
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:255)
at
oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:992)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
at
oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3454)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
at
org.apache.activemq.store.jdbc.DefaultDatabaseLocker.keepAlive(DefaultDatabaseLocker.java:104)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.databaseLockKeepAlive(JDBCPersistenceAdapter.java:458)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter$3.run(JDBCPersistenceAdapter.java:260)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
07:39:20,910 | ERROR | pool-flow.seda.servicemix-jms-thread-443 |
JmsComponent | emix.common.AsyncBaseLifeCycle 512 | Error
processing exchange InOnly[
id: ID:192.168.0.83-1224fe29298-8:258
status: Active
role: provider
service: {java://com.knapp.bus.jms.wms}wms2osr
endpoint: osrQueue
in: <?xml version="1.0" encoding="UTF-8"?><LCPROT route="OSR1"
service="SSSUBSYSTEM" version="1.1">
<REQUEST>NEW_TRANSPORT</REQUEST>
<REQUESTID>LCPRID0000000097</REQUESTID>
<NEW_TRANSPORT>
<DATAFORMAT>SSSUBSYSTEM.XML</DATAFORMAT>
<DATATYPE>TEXT</DATATYPE>
<DATA format="SSSUBSYSTEM.XML" name="wms2wcs" type="TEXT">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?><wms2wcs><exp_event
action="ADD" dcr="2009-07-07 06:27:59" dmr="" errorid="" id="" status="10"
sub_action="TRANSPORT" systemid="01" ><exp_container cntno="0" cont_refno=""
conttypeid="10" creation_date="2009-07-07 06:27:59" errorid="" event_id=""
licenceplate="803184" lock_state="N" person="" priority="0" returns_flag=""
status="" weight_act="21000" weight_tara="" wpono="354629" wptypeid="RP"
/><exp_ws bundlesize="1" cntno="0" creation_date="2009-07-07 06:27:59"
errorid="" event_id="" expiry_date="2009-12-03 00:00:00"
flag_check_required="" flag_fefo="Y" flag_lot="" height=""
item_description="SADJE SUHO EKSOTI�NO ME�." itembarcode="" itemgroup=""
itemno="P629277" itemtype="WEIGHT" itemweight="" lbarcode="" length=""
locno="5200111" lot_change="" lot_number="" person=""
pick_location="OSR12DEG" priority="0" qty="8000" status="" unit="1000"
volume="" width="" wpono="354629" ws_no="1" ws_seq="" ws_type="GET"
><exp_cont_qty bundlename="PE1" bundlesize="1" conttypeid="10"
itemno="P629277" qty="20" wpono="354629" ws_no="1" /></exp_ws><exp_ws
bundlesize="1" cntno="0" creation_date="2009-07-...
]
javax.jms.JMSException: java.io.EOFException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1201)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1644)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:227)
at
org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:241)
at
org.apache.servicemix.jms.multiplexing.MultiplexingProviderProcessor.process(MultiplexingProviderProcessor.java:114)
at org.apache.servicemix.soap.SoapEndpoint.process(SoapEndpoint.java:367)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:600)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:554)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.onMessageExchange(AsyncBaseLifeCycle.java:510)
at
org.apache.servicemix.common.SyncLifeCycleWrapper.onMessageExchange(SyncLifeCycleWrapper.java:60)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:620)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:168)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:269)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:203)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:195)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
... 1 more
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24368255.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi,
it looks like that the jms component is not responding. I turned
org.apache.servicemix to DEBUG mode and got the following result:
09:07:01,715 | INFO | 841533 Client-Thread - /192.168.0.83:2342 |
LcpMessageHandler | .handler.lcp.LcpMessageHandler 127 | Message
received from WMS: <our xml messag/>
09:07:01,715 | INFO | 841533 Client-Thread - /192.168.0.83:2342 |
TcpConsumerEndpoint | .bus.tcpbc.TcpConsumerEndpoint 254 | Message
send to bus: <our xml messag/>
09:07:01,715 | INFO | 841533 Client-Thread - /192.168.0.83:2342 |
PERFORMANCE | .bus.tcpbc.TcpConsumerEndpoint 257 | Before Bus
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 458 | SendSync
ID:192.168.0.83-12211367016-27:140 in DeliveryChannel{tcpbc}
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 458 | SendSync
ID:192.168.0.83-12211367016-27:140 in DeliveryChannel{tcpbc}
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
SecuredBroker | mix.jbi.security.SecuredBroker 66 | send
exchange with secure broker
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
SecuredBroker | mix.jbi.security.SecuredBroker 72 | service
name :{http://servicemix.apache.org/eip/1.0}content-router
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
SecuredBroker | mix.jbi.security.SecuredBroker 73 | operation
name :null
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 | SedaFlow
| emix.jbi.nmr.flow.AbstractFlow 118 | Called Flow send
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 | SedaFlow
| emix.jbi.nmr.flow.AbstractFlow 118 | Called Flow send
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 703 | Waiting for
exchange ID:192.168.0.83-12211367016-27:140 (15a6af3) to be answered in
DeliveryChannel{tcpbc} from sendSync
09:07:01,715 | DEBUG | 841533 Client-Thread - /192.168.0.83:2342 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 703 | Waiting for
exchange ID:192.168.0.83-12211367016-27:140 (15a6af3) to be answered in
DeliveryChannel{tcpbc} from sendSync
09:07:01,715 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 | SedaQueue
| .jbi.nmr.flow.seda.SedaQueue$1 132 |
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@9412a dequeued exchange:
InOnly[
id: ID:192.168.0.83-12211367016-27:140
status: Active
role: provider
service: {http://servicemix.apache.org/eip/1.0}content-router
endpoint: eip:routerEndpoint
in: <our xml messag/>]
09:07:01,715 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 | SedaQueue
| .jbi.nmr.flow.seda.SedaQueue$1 132 |
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@9412a dequeued exchange:
InOnly[
id: ID:192.168.0.83-12211367016-27:140
status: Active
role: provider
service: {http://servicemix.apache.org/eip/1.0}content-router
endpoint: eip:routerEndpoint
in: <our xml messag/>]
09:07:01,715 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
EIPComponent | emix.common.AsyncBaseLifeCycle 534 | Received
exchange: status: Active, role: provider
09:07:01,715 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
EIPComponent | emix.common.AsyncBaseLifeCycle 596 | Retrieved
correlation id: ID:192.168.0.83-12211367016-27:140
09:07:01,715 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
MemoryStore | cemix.store.memory.MemoryStore 51 | Storing
object with id: ID:192.168.0.83-12211367016-27:140
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
EIPComponent | emix.common.AsyncBaseLifeCycle 632 | Correlation
id retrieved from ThreadLocal: ID:192.168.0.83-12211367016-27:140
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 425 | Send
ID:192.168.0.83-12211367016-8:211 in DeliveryChannel{servicemix-eip}
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 425 | Send
ID:192.168.0.83-12211367016-8:211 in DeliveryChannel{servicemix-eip}
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
SecuredBroker | mix.jbi.security.SecuredBroker 66 | send
exchange with secure broker
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
SecuredBroker | mix.jbi.security.SecuredBroker 72 | service
name :{java://com.knapp.bus.jms.wms}wms2osr
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 |
SecuredBroker | mix.jbi.security.SecuredBroker 73 | operation
name :null
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 | SedaFlow
| emix.jbi.nmr.flow.AbstractFlow 118 | Called Flow send
09:07:01,731 | DEBUG | pool-flow.seda.servicemix-eip-thread-298 | SedaFlow
| emix.jbi.nmr.flow.AbstractFlow 118 | Called Flow send
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24198170.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi!
Today i have the stack dump and the debug logs from servicemix. I attached
the file to this message.
http://www.nabble.com/file/p24180257/servicemixStack20090624.txt
servicemixStack20090624.txt
Here is a debug log which "hangs". I wonder why there are some lines double
(except the logs of our component)?:
http://www.nabble.com/file/p24180257/hangingRequestComplete.txt
hangingRequestComplete.txt
And here is a log file when everything works fine (except that the logs are
also double).
http://www.nabble.com/file/p24180257/okRequestComplete.txt
okRequestComplete.txt
In the files you can see the complete flow from a request received by our
TCP BC and send to the jms queue. There is always a log when the message
arrives and also one when the message is put on the bus. I hope you can help
me with this. The thread settings and so on are not touched. The bus has the
original settings from the download.
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24180257.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Gert Vanthienen <ge...@gmail.com>.
Christian,
Yes, the CBR should send back DONE/ERROR to the TCP BC based on the reponse
it gets from the exchanges it forwarded. So it that exchange ends in ERROR,
the result should be an ERROR going back to the TCP BC.
I misunderstood about the JMS thing there, I thought you were using a custom
component for that as well. Sorry about that...
One more thing: in your efforts to troubleshoot this, it would be helpful if
you could get us a thread dump tomorrow morning when the system is stuck
(cfr.
http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/)
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/6/23 Christian Graf <ch...@knapp.com>
>
> Hi!
>
>
> >Christian,
>
> >Regardless of sync/async mode, you will always get the same
> >MessageExchange interactions in the ESB. In your scenario, an ACTIVE
> >exchange would be sent from the TCP BC to the CBR. The CBR would then
> >send another ACTIVE exchange to the queue component. Once the last
> >component has done its work, it would send back a DONE exchange to the
> >CBR and only then would the first exchange be answered with DONE.
>
> This means, if the CBR fails to send the message to the jms queue (e.g.
> wrong route) the exchange will be
> answered with ERROR?
>
> >My guess is that the last component somehow fails to handle the
> >message or send back the DONE exchange after a long period of idleness
> >and that this is blocking your ESB interactions.
>
> >Just one additional question: why are you using a custom component to
> >send messages to JMS queues? Is there a feature we can add to our
> >default servicemix-jms component to make that work for your use case
> >as well?
>
> I am not sure if i understand your question corret. What du you mean with
> "custom component".
> We use the standard servicemix-jms component. As persistance store i added
> a
> oracle database.
>
> The CBR is used do send the message to the correct queue base on the
> "route"
> entry.
>
> The TCP component is our communication BC which interacts with an ERP
> (Warehouse Management System) system. This component reads the messages
> send
> by the ERP system via TCP, verify s the content and forwards it to the
> CBR.
> The TCP BC also has some "special" logging and reporting functions (done
> via
> CORBA) to interact with the reporting system of the ERP system.
>
> Our second component consumes the messages from the queue. This component
> transforms the message to the required "output" format and sends it to the
> system in the storage zone (this are completely automated storage systems).
> It also handles the connection handling and so on.
>
> I hope this answers your questions. If not do not hesitate to ask again.
>
> Regards,
> Christian
>
> >Regards,
>
> >Gert Vanthienen
> >------------------------
> >Open Source SOA: http://fusesource.com
> >Blog: http://gertvanthienen.blogspot.com/
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24162861.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi!
>Christian,
>Regardless of sync/async mode, you will always get the same
>MessageExchange interactions in the ESB. In your scenario, an ACTIVE
>exchange would be sent from the TCP BC to the CBR. The CBR would then
>send another ACTIVE exchange to the queue component. Once the last
>component has done its work, it would send back a DONE exchange to the
>CBR and only then would the first exchange be answered with DONE.
This means, if the CBR fails to send the message to the jms queue (e.g.
wrong route) the exchange will be
answered with ERROR?
>My guess is that the last component somehow fails to handle the
>message or send back the DONE exchange after a long period of idleness
>and that this is blocking your ESB interactions.
>Just one additional question: why are you using a custom component to
>send messages to JMS queues? Is there a feature we can add to our
>default servicemix-jms component to make that work for your use case
>as well?
I am not sure if i understand your question corret. What du you mean with
"custom component".
We use the standard servicemix-jms component. As persistance store i added a
oracle database.
The CBR is used do send the message to the correct queue base on the "route"
entry.
The TCP component is our communication BC which interacts with an ERP
(Warehouse Management System) system. This component reads the messages send
by the ERP system via TCP, verify s the content and forwards it to the CBR.
The TCP BC also has some "special" logging and reporting functions (done via
CORBA) to interact with the reporting system of the ERP system.
Our second component consumes the messages from the queue. This component
transforms the message to the required "output" format and sends it to the
system in the storage zone (this are completely automated storage systems).
It also handles the connection handling and so on.
I hope this answers your questions. If not do not hesitate to ask again.
Regards,
Christian
>Regards,
>Gert Vanthienen
>------------------------
>Open Source SOA: http://fusesource.com
>Blog: http://gertvanthienen.blogspot.com/
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24162861.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Gert Vanthienen <ge...@gmail.com>.
Christian,
Regardless of sync/async mode, you will always get the same
MessageExchange interactions in the ESB. In your scenario, an ACTIVE
exchange would be sent from the TCP BC to the CBR. The CBR would then
send another ACTIVE exchange to the queue component. Once the last
component has done its work, it would send back a DONE exchange to the
CBR and only then would the first exchange be answered with DONE.
My guess is that the last component somehow fails to handle the
message or send back the DONE exchange after a long period of idleness
and that this is blocking your ESB interactions.
Just one additional question: why are you using a custom component to
send messages to JMS queues? Is there a feature we can add to our
default servicemix-jms component to make that work for your use case
as well?
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/6/23 Christian Graf <ch...@knapp.com>:
>
> Hi!
>
> Thanks for the responses.
> I'll enable more debug informations this evening so i can get more
> informations tomorrow morning.
> I'll also check the link about the thread pool.
>
> @Gert Vanthienen: The system is (should) working the following way: TCP BC
> receives the message and puts it on the bus. From there it's send to the EIP
> Content Router. The router decides in which queue the message will be put.
> Each queue has it's own BC which receives the messages from the queue and
> handles it. As far is i understand is that in async mode i only get a
> response if the message from TCP BC have reached the EIP Content Router
> successfully but i do not get any information back if the transport from the
> EIP Content Router to the queue has worked. Therefor i use the sync mode.
>
> Regards,
> Christian
> --
> View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24162021.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi!
Thanks for the responses.
I'll enable more debug informations this evening so i can get more
informations tomorrow morning.
I'll also check the link about the thread pool.
@Gert Vanthienen: The system is (should) working the following way: TCP BC
receives the message and puts it on the bus. From there it's send to the EIP
Content Router. The router decides in which queue the message will be put.
Each queue has it's own BC which receives the messages from the queue and
handles it. As far is i understand is that in async mode i only get a
response if the message from TCP BC have reached the EIP Content Router
successfully but i do not get any information back if the transport from the
EIP Content Router to the queue has worked. Therefor i use the sync mode.
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24162021.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Gert Vanthienen <ge...@gmail.com>.
Christian,
Even for an InOnly exchange if you use send, you will always get back an
ERROR/DONE MessageExchange that tells you whether or not the send to the
ActiveMQ queue has been successful. Increasing the thread pools would be
one solution, but my guess is that after an idle night, one of the
components fails to recreate connections or something like that. As long as
the EIP component has not received a DONE status from all the components it
has sent an exchange to, it will not reply to the TCP BC you created.
The best way to troubleshoot this is probably by enabling DEBUG logging
(which you already have) and then looking at the MessageExchanges and
especially at the statuses. You're looking for exchanges that have status
ACTIVE and that never get answered with DONE -- if you find those, you've
probably found the component that's having the problem.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/6/23 Christian Graf <ch...@knapp.com>
>
> Hi,
>
> thanks for the reply. The problem is that i have to ensure that the message
> reaches the Active MQ "safely" and in the same order as received. This is
> ensured by using "sendSync". "send" is asynchronous and that's to unsafe
> for
> our needs. :( Is there any other possibility?
>
> Regards,
> Christian
> --
> View this message in context:
> http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24161386.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi,
thanks for the reply. The problem is that i have to ensure that the message
reaches the Active MQ "safely" and in the same order as received. This is
ensured by using "sendSync". "send" is asynchronous and that's to unsafe for
our needs. :( Is there any other possibility?
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24161386.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Seems this is caused by the thread pool run out when you use sendSync,
there's no more thread to do the notify.
Could you use send instead?
Freeman
Christian Graf wrote:
> Hi again,
>
> today we got the same problem. I changed the log4j settings for
> org.apache.servicemix.jbi.messaging to Debog and got the following lines:
>
> 08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
> DeliveryChannelImpl | .messaging.DeliveryChannelImpl 458 | SendSync
> ID:192.168.0.83-122085becd7-27:322 in DeliveryChannel{tcpbc}
> 08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
> DeliveryChannelImpl | .messaging.DeliveryChannelImpl 703 | Waiting for
> exchange ID:192.168.0.83-122085becd7-27:322 (9d4352) to be answered in
> DeliveryChannel{tcpbc} from sendSync
>
> This is the last line in the log file. Does anyone have a clue what's going
> on there?
>
> Regards,
> Christian
>
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Maciej Prochniak <mp...@touk.pl>.
It seems that tcpbc component doesn't receive acknowledgement (DONE
status) and waits indefinitely - thus blocking thread. Could you turn
debug on org.apache.servicemix.jbi.nmr.flow - then you would see
messages being sent. Probably DONE message is not sent either from
ActiveMQ or EIP or it's not properly handled by tcpbc component
- not knowing exact configuration it's hard to guess
br,
maciek
On Mon, 2009-06-22 at 23:33 -0700, Christian Graf wrote:
> Hi again,
>
> today we got the same problem. I changed the log4j settings for
> org.apache.servicemix.jbi.messaging to Debog and got the following lines:
>
> 08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
> DeliveryChannelImpl | .messaging.DeliveryChannelImpl 458 | SendSync
> ID:192.168.0.83-122085becd7-27:322 in DeliveryChannel{tcpbc}
> 08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
> DeliveryChannelImpl | .messaging.DeliveryChannelImpl 703 | Waiting for
> exchange ID:192.168.0.83-122085becd7-27:322 (9d4352) to be answered in
> DeliveryChannel{tcpbc} from sendSync
>
> This is the last line in the log file. Does anyone have a clue what's going
> on there?
>
> Regards,
> Christian
Re: Servicemix 3.3 SendSync hangs after one night in idle mode.
Posted by Christian Graf <ch...@knapp.com>.
Hi again,
today we got the same problem. I changed the log4j settings for
org.apache.servicemix.jbi.messaging to Debog and got the following lines:
08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 458 | SendSync
ID:192.168.0.83-122085becd7-27:322 in DeliveryChannel{tcpbc}
08:27:36,326 | DEBUG | 573793 Client-Thread - /192.168.0.83:2997 |
DeliveryChannelImpl | .messaging.DeliveryChannelImpl 703 | Waiting for
exchange ID:192.168.0.83-122085becd7-27:322 (9d4352) to be answered in
DeliveryChannel{tcpbc} from sendSync
This is the last line in the log file. Does anyone have a clue what's going
on there?
Regards,
Christian
--
View this message in context: http://www.nabble.com/Servicemix-3.3-SendSync-hangs-after-one-night-in-idle-mode.-tp24143726p24160656.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.