Quite confusing situation had resolved couple minutes ago.
The history was started by Sibel implementation team, they have noticed strange hangs for 5-7 seconds while user process orders. So they started investigation and founded the reason (They think so). There were detected strange Siebel EAI behavior.
The next step was mine. I've create the simplest WSDL for a echoing Proxy Service, and ran several tests with different scenarios, using soapUI.
Well there is no timeouts at all. Actually there were several really long responses, but the min response time was around 5-9 ms, and any average less 100 ms.
I've sent porject, report and explanation to Siebel team. Pong!
Guys from other side reproduced the test and found the root of the issue.
soapUI uses header user-agent with a value Jakarta Commons-HttpClient/3.0.1, meanwhile Siebel EAI set user-agent to Mozilla/4.0. Ping !
Hmm, quite strange. When I set user-agent to Mozilla/4.0 I get the same result, the client (soapUI in my case), waits for a keepAliveTimeout and only then responses.
So i don't know how the system behavior will be changed if I switch off keepAlive.
But what I know, that you can change only one parameter in Siebel Enterprise Application Integration and avoid such cumbersome cases.
The history was started by Sibel implementation team, they have noticed strange hangs for 5-7 seconds while user process orders. So they started investigation and founded the reason (They think so). There were detected strange Siebel EAI behavior.
- EAI receive request from a Siebel user
- Send it to our LBR-OHS and OSB cluster process it.
- Then OSB send response back to EAI
- EAI waits for a 5 second
- And then send respond to user.
The next step was mine. I've create the simplest WSDL for a echoing Proxy Service, and ran several tests with different scenarios, using soapUI.
Well there is no timeouts at all. Actually there were several really long responses, but the min response time was around 5-9 ms, and any average less 100 ms.
I've sent porject, report and explanation to Siebel team. Pong!
Guys from other side reproduced the test and found the root of the issue.
soapUI uses header user-agent with a value Jakarta Commons-HttpClient/3.0.1, meanwhile Siebel EAI set user-agent to Mozilla/4.0. Ping !
Hmm, quite strange. When I set user-agent to Mozilla/4.0 I get the same result, the client (soapUI in my case), waits for a keepAliveTimeout and only then responses.
So i don't know how the system behavior will be changed if I switch off keepAlive.
But what I know, that you can change only one parameter in Siebel Enterprise Application Integration and avoid such cumbersome cases.
No comments:
Post a Comment