0
votes

I have a simple passthrough proxy in WSO2 ESB 5.0.0 to a WSO2 DSS. When I consume the esb proxy the live treads classes loaded increase until WSO2 ESB breaks down. When esb breaks down there are 284 threads and 14k classes load. If I consume the DSS directly, dss doesn't break down and the maximun threads are 104 and 9k classes loaded.

How can I force esb releases that resources, or improve how the esb handle the http connections in esb? Looks like zombie connections never release the thread.

Any help to focus the problem?

1
Looks like endpoint in simple passthrought proxy doesn't return OK immediately. What is average request per second on proxy and average response time of endpoint?simar
No many request. The scenario is an app consuming the esb service, that has several tabs where it consume the esb. After 45 quickly changes of tab in the app, esb breaks down. It is like dss responds to esb, but esb cannot respond because the app finish the connection (changing the tab), and the thead gets kind of zombie or block.fipries
What protocol is used between app and esb server?simar
Can u add details how DSS and ESB connection is made? Same machine? Dss services is called over http? Local transport is used ?simar
different machines, using http.fipries

1 Answers

1
votes

Doesn't look that problem with classloading and thread count. I just finished to test newly installed WSO2ESB server.

  • WSOESB version 5.0.0
  • java8
  • Windows 8
  • Esb server as well has DSS feature installed.
  • DSS services is called over http1.1 protocol.
  • DSS service has long running query (over 10s)
  • Total number of simultaneously requests to ESB service over 150

Total number of loaded classes over 15000 total threads running over 550. Even in this high load there is no any issuer like you mention.

What i actually recommend is to check how you make http requests to esb service. It is kind of sensitive to headers like Content-Type, Encoding. It took quiet long time to find out how properly call soap service on esb, using apache httpclient (4.5)

Eventually probably find out then problem. Problem is between DSS and ESB servers. According to source code, this kind of error happen, when esb send request to dss server and request is read by DSS server but connection to DSS server is closed before DSS server write response to ESB server. Then esb server report message about such problem as your mention

SourceHandler

...
 } else if (state == ProtocolState.REQUEST_DONE) {
            isFault = true;
            log.warn("Connection closed by the client after request is read: " + conn);
        }

Easy to reproduce start esb and dss server. Start sending a lots of requests to passthrough proxy (which proxy request to DSS service) on ESB, shutdown DSS server and you will see a lot of

WARN - SourceHandler Connection closed by the client after request is read:   http-incoming-1073 Remote Address

This is might be network issuer, firewall or as well WsoDSS server has socket timeout which is by default 180s.