On May 21, 2014, at 7:28 AM, Aniket Bhoi <aniket.b...@gmail.com> wrote:
> On Tue, May 20, 2014 at 5:28 PM, Daniel Mikusa <dmik...@gopivotal.com>wrote: > >> On May 20, 2014, at 7:47 AM, Aniket Bhoi <aniket.b...@gmail.com> wrote: >> >>> It has been working perfectly fine thus far.As far as i have analysed >> there >>> have been no changes to the firewall or database settings.I will however >>> try and implement your suggestion to setup a validation query. >> >> 1.) Don’t top post. Reply inline, like this, or at the bottom. This is >> the convention we follow on this list. >> >> 2.) The fact that you have not recently changed your firewall or database >> settings doesn’t really mean much. The problem may have not happened >> before because it just didn’t get triggered. From the db / firewall side, >> what commonly causes this is a timeout. The connection is open and idle >> for too long and either the DB server or firewall disconnects it. Perhaps >> the connections just haven’t idled long enough until now. >> >> 3.) It’s generally good practice to have a validation query / testOnBorrow >> (or one of the other tests) enabled. If you didn’t have this before, you >> should consider adding it regardless of the problem. It can help with >> other things too. >> >> Dan >> >> >> I checked the code and the server settings,and We already have > validation query and testOnBorrow in place. I suspect that there’s more to it than this. Perhaps you could share your configuration? > We found out from our data > management team,that there have been many sleeping connections from the > tomcat servers to the database. This sounds normal to me. A connection pool will maintain idle connections that do nothing. It sounds like you’re not expecting to see this? > > Sleeping threads = > http://dinesql.blogspot.in/2010/07/sql-server-sleeping-status-and.html > > We got those connection threads killed just to make sure there the > connection pool limit isnt breached. Do you not trust the connection pool? If you set a limit in the pool, it won’t go past that. > However even after cleaning up those > connection threads to the DB ,we still gett the same exception. Dropping connections from the server side will very likely cause the exception that you’re reporting. Since you’re dropping the connection outside of the pool, the pool has no idea that the connection has been closed. Thus you get the exception you’re reporting. Dan > > Aniket > >>> >>> >>> On Tue, May 20, 2014 at 5:12 PM, Daniel Mikusa <dmik...@gopivotal.com >>> wrote: >>> >>>> On May 20, 2014, at 7:35 AM, Aniket Bhoi <aniket.b...@gmail.com> wrote: >>>> >>>>> I have Apache Solr,hosted on my apache Tomcat Server >>>>> >>>>> Details: >>>>> >>>>> Tomcat version: >>>>> Apache Tomcat/6.0.18 >>>> >>>> This is really, really old. You should upgrade. >>>> >>>>> >>>>> OS details >>>>> SUSE Linux Enterprise Server 11 (x86_64) >>>>> VERSION = 11 >>>>> PATCHLEVEL = 1 >>>>> >>>>> While running indexing on this server,It failed. >>>>> >>>>> Log excerpt: >>>>> SEVERE: Can not close connection >>>>> java.sql.SQLException: Already closed. >>>> >>>> Hard to say why this is happening (database server setting, firewall, >> bad >>>> code, etc.) but something is closing the connection and not telling the >>>> pool. You can work around this by setting a validation query on your >>>> connection pool and enabling “testOnBorrow”. That will instruct the >> pool >>>> to check connections before they are given out. Bad connections will be >>>> closed and replaced, if needed. >>>> >>>> Dan >>>> >>>>> at >>>>> >>>> >> org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:84) >>>>> at >>>>> >>>> >> org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:189) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.closeResources(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.access$500(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(Unknown >>>>> Source) >>>>> at >>>>> org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(Unknown >>>>> Source) >>>>> at >>>>> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.ThreadedEntityProcessorWrapper.nextRow(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.runAThread(Unknown >>>>> Source) >>>>> at >>>>> >>>> >> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.access$000(Unknown >>>>> Source) >>>>> at >>>>> >> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner$1.run(Unknown >>>>> Source) >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown >>>>> Source) >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>> Source) >>>>> at java.lang.Thread.run(Unknown Source) >>>>> >>>>> >>>>> I suspect this to be an issue with the tomcat connection thread to the >>>>> database being terminated/timed out. >>>>> >>>>> Need help as to why this is happening!. >>>>> >>>>> Regards >>>>> >>>>> Aniket >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
