Jaromír Talíř
2008-11-06 21:24:23 UTC
Hi,
we spotted some strange behavior regarding to omniORB threads. Our
client received CORBA::UNKNOWN exception, probably as a result of
bad_alloc in code (I'm not sure but this is most possible). But server
thread of this request stays in some locked state and under heavy load
clients start to receive CORBA::COMM_FAILURE. According to 'ps -efL'
there is a thread from the time of this exception so I suspect omniORB
that he is trying to assign this broken thread to some request and this
request fails. Not all corba calls fail but more connections there are,
more COMM_FAILURE we see. When we restart server, everything is OK.
I didn't succeed in reproducing this behavior in testing environment so
it's just my guess.
We use omniORB-4.0.6 on Ubuntu 6.06 Dapper with default configuration:
threadPerConnectionPolicy = 1
maxServerThreadPerConnection = 100
maxServerThreadPoolSize = 100
threadPerConnectionUpperLimit = 10000
threadPerConnectionLowerLimit = 9000
Our high traffic is about 50 concurrent connections.
Is there a possibility there was some bug in 4.0.6 regarding to thread
cleanup?
Regards,
Jaromir Talir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3870 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20081106/0137da0b/smime.bin
we spotted some strange behavior regarding to omniORB threads. Our
client received CORBA::UNKNOWN exception, probably as a result of
bad_alloc in code (I'm not sure but this is most possible). But server
thread of this request stays in some locked state and under heavy load
clients start to receive CORBA::COMM_FAILURE. According to 'ps -efL'
there is a thread from the time of this exception so I suspect omniORB
that he is trying to assign this broken thread to some request and this
request fails. Not all corba calls fail but more connections there are,
more COMM_FAILURE we see. When we restart server, everything is OK.
I didn't succeed in reproducing this behavior in testing environment so
it's just my guess.
We use omniORB-4.0.6 on Ubuntu 6.06 Dapper with default configuration:
threadPerConnectionPolicy = 1
maxServerThreadPerConnection = 100
maxServerThreadPoolSize = 100
threadPerConnectionUpperLimit = 10000
threadPerConnectionLowerLimit = 9000
Our high traffic is about 50 concurrent connections.
Is there a possibility there was some bug in 4.0.6 regarding to thread
cleanup?
Regards,
Jaromir Talir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3870 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20081106/0137da0b/smime.bin