On Thu, Feb 9, 2012 at 6:19 PM, Tharindu Mathew <[email protected]> wrote:
> ChamaraA, > > You increased the connection param values in BAM, right? Yes > > > On Thu, Feb 9, 2012 at 5:28 PM, Isuru Suriarachchi <[email protected]> wrote: > >> This error has occurred while the BAM publisher trying to publish stats >> to BAM and not when AS accepting messages. Therefore I think >> increasing maxThreads and maxConnections wont have any relationship to this >> particular problem. Should be related to some issue in the connection >> between AS and BAM. >> >> Thanks, >> ~Isuru >> >> On Thu, Feb 9, 2012 at 3:05 PM, Chamara Ariyarathne <[email protected]>wrote: >> >>> While testing with an AS cluster with two nodes with latest BAM2 >>> statistic publishers, loading with 500 messages with 50 concurrency, >>> I noticed following exception from time to time in AS side; >>> >>> [2012-02-09 12:01:01,004] ERROR >>> {org.wso2.carbon.bam.agent.publish.DataPublisher} - Unable to publish >>> event to BAM >>> org.apache.thrift.transport.TTransportException: >>> java.net.SocketException: Connection reset >>> at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:195) >>> at >>> org.wso2.carbon.bam.service.ReceiverService$Client.send_publish(ReceiverService.java:94) >>> at >>> org.wso2.carbon.bam.service.ReceiverService$Client.publish(ReceiverService.java:82) >>> at >>> org.wso2.carbon.bam.agent.publish.DataPublisher.publishUsingHttp(DataPublisher.java:216) >>> at >>> org.wso2.carbon.bam.agent.publish.DataPublisher.publish(DataPublisher.java:84) >>> at >>> org.wso2.carbon.bam.agent.queue.EventWorker.clearActivityDataQueue(EventWorker.java:63) >>> at org.wso2.carbon.bam.agent.queue.EventWorker.run(EventWorker.java:44) >>> 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:662) >>> Caused by: java.net.SocketException: Connection reset >>> at java.net.SocketInputStream.read(SocketInputStream.java:168) >>> at >>> com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293) >>> at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331) >>> at >>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798) >>> at >>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) >>> at >>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) >>> at >>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149) >>> at >>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) >>> at >>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) >>> at >>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) >>> at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:183) >>> ... 9 more >>> >>> As I found out, the solution for this is to increase the max threads and >>> max connections in http protocol in mgt-transports file, as >>> <parameter name="maxThreads">10000</parameter> (default 250) >>> <parameter name="maxConnections">10000</parameter> (default undefined; >>> value of maxThreads is taken) >>> >>> The tomcat config document says in maxConnections: >>> The maximum number of connections that the server will accept and >>> process at any given time. When this number has been reached, the server >>> will not accept any more connections until the number of connections falls >>> below this value. The operating system may still accept connections based >>> on the acceptCount setting. Default value varies by connector type. For BIO >>> the default is the value of maxThreads. For NIO the default is 10000. For >>> APR/native, the default is 8192. >>> Note that for APR/native on Windows, the configured value will be >>> reduced to the highest multiple of 1024 that is less than or equal to >>> maxConnections. This is done for performance reasons. >>> >>> *Still even with this configuration, I get the above exception but not >>> frequently. * >>> >>> -- >>> *Chamara Ariyarathne* >>> Software Engineer - QA; >>> WSO2 Inc; http://www.wso2.com/. >>> Mobile; *0772786766* >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Isuru Suriarachchi >> Technical Lead >> WSO2 Inc. http://wso2.com >> email : [email protected] >> blog : http://isurues.wordpress.com/ >> >> lean . enterprise . middleware >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > Regards, > > Tharindu > > blog: http://mackiemathew.com/ > M: +94777759908 > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- *Chamara Ariyarathne* Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; *0772786766*
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
