You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com> on 2008/01/11 16:40:48 UTC
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
[I resend this message because I hadn't confirmed the subscription to
the list before sending. Sorry for all those that might receive it
twice]
Hello,
I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
into attention.
It seems that either an old problem is resurging (not really solved),
or that we have some configuration problems, so I would appreciate
your help.
Every hour (approximately), suddenly, without a gradual increase in
thread count etc, a deadlock(?) suddenly rises the charge in our web
application and within seconds, the application is dead.
We tend to see threads like the following through jconsole when this happens:
Name: TP-Processor431
State: WAITING on java.lang.Object@253e7f
Total blocked: 4 388 Total waited: 248
Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474)
com.ibatis.common.util.Throttle.increment(Throttle.java:70)
com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecutorDelegate.java:930)
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.java:51)
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapClientImpl.java:258)
The database configuration is like this in our Spring 2.5.1
configuration files, for approximately 1000 connected users:
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
[..]
<property name="maxActive" value="100"/>
<property name="maxIdle" value="30"/>
<property name="maxWait" value="10000"/>
</bean>
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Clinton Begin <cl...@gmail.com>.
If you're using Spring, then the transaction/session scope is managed
completely by Spring. Somehow you'll have to verify the same thing I
mentioned, but within the context of Spring... make sure the transactions
are guaranteed to be opened and closed consistently and in a fault tolerant
way...
Also, try building iBATIS from the trunk, just to see what kind of error you
get. It might help debug it, because the new error will likely be from your
datasource and/or connection.
Clinton
-----Original Message-----
From: Stéphane Hanser [mailto:s.hanser@omegames.com]
Sent: January-11-08 6:08 PM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Hi everybody.
I join this discussion because I'm working with Nikolas on this
project and I'm fighting with this problem as well.
Thank you very much for your answer. However I don't know yet how it
will help us.
Indeed we never use SqlMapClient but only SqlMapClientTemplate and we
don't use transaction either.
I agree with you when you says that we're out of connections but this
is the point. The application behaves as if sessions weren't closed.
We saw on th MySQL server that there was about as many connections as
the maxActive parameter. All the connections were in sleep.
We use commons-dbcp for our datasource (BasicDataSource).
What do you think could bring to this kind of behavior?
Thanks a lot
Stéphane Hanser
Le 11 janv. 08 à 22:39, Clinton Begin a écrit :
> It's most likely that somewhere in your code you're not properly
> ending a
> transaction or closing a session.... Every single SqlMapClient usage
> should
> be wrapped with something like this (unless you're not using a
> transaction
> at all):
>
> try {
> // start
> // work
> // commit
> } finally {
> // end
> }
>
> Incidentally, if you want to grab the latest source from the trunk
> and build
> it (simple to do), I've completely removed all of the pooled
> scopes. While
> this likely won't solve your problem, the stack trace will likely
> point you
> to your datasouce and it will appear instead as though you're
> running out of
> connections (unless you're using our simpledatasource, in which case
> the
> connections will be forcefully reclaimed and you may never know
> about the
> problem).
>
> I'd do a thorough check of all SqlMapClient usages and make sure
> they're in
> try/finally blocks and that there is exactly the same number of
> starts as
> there are ends... (global text search can usually do this fairly
> easily).
>
> Clinton
>
>
> -----Original Message-----
> From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com
> ]
> Sent: January-11-08 8:41 AM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> [I resend this message because I hadn't confirmed the subscription to
> the list before sending. Sorry for all those that might receive it
> twice]
>
> Hello,
> I would like to bring this:
https://issues.apache.org/jira/browse/IBATIS-249
> into attention.
> It seems that either an old problem is resurging (not really solved),
> or that we have some configuration problems, so I would appreciate
> your help.
>
> Every hour (approximately), suddenly, without a gradual increase in
> thread count etc, a deadlock(?) suddenly rises the charge in our web
> application and within seconds, the application is dead.
> We tend to see threads like the following through jconsole when this
> happens:
>
> Name: TP-Processor431
> State: WAITING on java.lang.Object@253e7f
> Total blocked: 4 388 Total waited: 248
>
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:474)
> com.ibatis.common.util.Throttle.increment(Throttle.java:70)
> com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
> orDelegate.java:930)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
> a:51)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
> lientImpl.java:258)
>
>
> The database configuration is like this in our Spring 2.5.1
> configuration files, for approximately 1000 connected users:
>
> <bean id="dataSource"
> class="org.apache.commons.dbcp.BasicDataSource"
> destroy-method="close">
> [..]
> <property name="maxActive" value="100"/>
> <property name="maxIdle" value="30"/>
> <property name="maxWait" value="10000"/>
> </bean>
>
>
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com>.
Sorry, please ignore the last message, we solved the log configuration problem.
>
> We actually have trouble activating log4j. It might or might not be
> the proper place to ask this question, but it would be really useful
> to know if you could spot the problem in the following configuration.
> Thanks for the help anyway!
>
--
Gobelin Survivant du dev de www.650km.com
http://recursive-cacophony.net/tec-goblin
http://googoomucks.blogspot.com
--------------------------------------------------------------------------
no creed on earth can replace or provide
in my darkest hour, the comfort I'd feel
leading me to see I can be more than I expect of me
vnv nation
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com>.
> > You could set the java.sql logging category to DEBUG and then you'd be able
> > to trace which statements are blocking. This will generate a lot of logfile
> > data, so be ready for it.
>
> Ok, we are configuring it at the moment. Stay tuned ;)
>
We actually have trouble activating log4j. It might or might not be
the proper place to ask this question, but it would be really useful
to know if you could spot the problem in the following configuration.
Thanks for the help anyway!
--log4j--
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - <%m>%n
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.File=D:\test.log
log4j.appender.logfile.MaxFileSize=512KB
log4j.appender.logfile.MaxBackupIndex=3
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n
log4j.rootLogger=debug, logfile, stdout
log4j.logger.com.ibatis=debug
log4j.logger.com.ibatis.common.jdbc.ScriptRunner=debug
log4j.logger.com.ibatis.sqlmap.engine.impl.SqlMapClientDelegate=debug
log4j.logger.java.sql.Connection=debug
log4j.logger.java.sql.Statement=debug
log4j.logger.java.sql.PreparedStatement=debug
log4j.logger.java.sql.ResultSet=debug
log4j.logger.org.springframework.transaction=debug
log4j.logger.org.springframework.orm=debug
--web.xml--
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
--
Gobelin Survivant du dev de www.650km.com
http://recursive-cacophony.net/tec-goblin
http://googoomucks.blogspot.com
--------------------------------------------------------------------------
no creed on earth can replace or provide
in my darkest hour, the comfort I'd feel
leading me to see I can be more than I expect of me
vnv nation
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Clinton Begin <cl...@gmail.com>.
>> It probably was about a conflict in dependencies with groovy.
iBATIS has no required dependencies, but yeah, if it found an incompatible
version of commons logging, cglib or log4j, it might have issues.
If it turns out that the newer versions are not compatible, let us know and
we'll upgrade them in 2.3.1... Yay for JAR hell!
Clinton
-----Original Message-----
From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com]
Sent: January-14-08 11:37 AM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
2008/1/14, Clinton Begin <cl...@gmail.com>:
> Any details on that?
We observed the phenomenon of multiple sessions waiting on Throttle
(despite the fact that all session handling is done by Spring and not
by us) on Throttle.increment, despite the fact that the database had
all connections sleeping and waiting to be used.
>
> Sorry this is so hard to debug, but if you're using Spring and Groovy on
top
> of iBATIS, you'll have a heck of a stack trace to debug through....
Indeed it's difficult to see if it's our configuration, ibatis or the
spring support for ibatis.
> Also, I'm confused why the version in the trunk wouldn't work...
It probably was about a conflict in dependencies with groovy.
>
> Clinton
>
> -----Original Message-----
> From: Stéphane Hanser [mailto:s.hanser@omegames.com]
> Sent: January-14-08 9:25 AM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> We also tried to use the last ibatis version from svn but it doesn't
> work with our application (it seems that tere are compatibility issues
> with groovy or something)
>
>
> Le 14 janv. 08 à 12:47, Nikolas Kyriazopoulos Panagiotopoulos a écrit :
>
> >> Could you possibly have an old iBATIS jar somewhere - maybe at the
> >> common
> >> or server level in Tomcat?
> > Not anymore.
> >
> >>
> >> What db and what version? If it's mysql, which type?
> > MySql 5.0.45 (client) 5.0.32-Debian_7etch3-log(server), InnoDb
> >
> >> What does the jdbc URL look like? Are you passing any special
> >> arguments
> >> via the JDBC URL?
> > jdbc:mysql://<an ip address here>/<database name here>
> > no arguments to my knowledge (apart from normal username and
> > password)
> >
> >> Are you using straight SQL in the SqlMaps or are you using stored
> >> procedures?
> > Straight SQL only
> >
> >> Are you seeing any locks in the db itself?
> > No.
> >
> >> You could set the java.sql logging category to DEBUG and then you'd
> >> be able
> >> to trace which statements are blocking. This will generate a lot
> >> of logfile
> >> data, so be ready for it.
> >
> > Ok, we are configuring it at the moment. Stay tuned ;)
> >
>
>
--
Gobelin Survivant du dev de www.650km.com
http://recursive-cacophony.net/tec-goblin
http://googoomucks.blogspot.com
--------------------------------------------------------------------------
no creed on earth can replace or provide
in my darkest hour, the comfort I'd feel
leading me to see I can be more than I expect of me
vnv nation
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com>.
2008/1/14, Clinton Begin <cl...@gmail.com>:
> Any details on that?
We observed the phenomenon of multiple sessions waiting on Throttle
(despite the fact that all session handling is done by Spring and not
by us) on Throttle.increment, despite the fact that the database had
all connections sleeping and waiting to be used.
>
> Sorry this is so hard to debug, but if you're using Spring and Groovy on top
> of iBATIS, you'll have a heck of a stack trace to debug through....
Indeed it's difficult to see if it's our configuration, ibatis or the
spring support for ibatis.
> Also, I'm confused why the version in the trunk wouldn't work...
It probably was about a conflict in dependencies with groovy.
>
> Clinton
>
> -----Original Message-----
> From: Stéphane Hanser [mailto:s.hanser@omegames.com]
> Sent: January-14-08 9:25 AM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> We also tried to use the last ibatis version from svn but it doesn't
> work with our application (it seems that tere are compatibility issues
> with groovy or something)
>
>
> Le 14 janv. 08 à 12:47, Nikolas Kyriazopoulos Panagiotopoulos a écrit :
>
> >> Could you possibly have an old iBATIS jar somewhere - maybe at the
> >> common
> >> or server level in Tomcat?
> > Not anymore.
> >
> >>
> >> What db and what version? If it's mysql, which type?
> > MySql 5.0.45 (client) 5.0.32-Debian_7etch3-log(server), InnoDb
> >
> >> What does the jdbc URL look like? Are you passing any special
> >> arguments
> >> via the JDBC URL?
> > jdbc:mysql://<an ip address here>/<database name here>
> > no arguments to my knowledge (apart from normal username and
> > password)
> >
> >> Are you using straight SQL in the SqlMaps or are you using stored
> >> procedures?
> > Straight SQL only
> >
> >> Are you seeing any locks in the db itself?
> > No.
> >
> >> You could set the java.sql logging category to DEBUG and then you'd
> >> be able
> >> to trace which statements are blocking. This will generate a lot
> >> of logfile
> >> data, so be ready for it.
> >
> > Ok, we are configuring it at the moment. Stay tuned ;)
> >
>
>
--
Gobelin Survivant du dev de www.650km.com
http://recursive-cacophony.net/tec-goblin
http://googoomucks.blogspot.com
--------------------------------------------------------------------------
no creed on earth can replace or provide
in my darkest hour, the comfort I'd feel
leading me to see I can be more than I expect of me
vnv nation
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Clinton Begin <cl...@gmail.com>.
Any details on that?
Sorry this is so hard to debug, but if you're using Spring and Groovy on top
of iBATIS, you'll have a heck of a stack trace to debug through....
iBATIS is a fairly simple little library, but when you pile all of that
stuff on top it becomes pretty hard to find problems. Is there any way you
can build a simpler implementation of one of your features that sidesteps
all of the app layers you have, just to see if it's truly iBATIS or if it's
something else?
Also, I'm confused why the version in the trunk wouldn't work...
Clinton
-----Original Message-----
From: Stéphane Hanser [mailto:s.hanser@omegames.com]
Sent: January-14-08 9:25 AM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
We also tried to use the last ibatis version from svn but it doesn't
work with our application (it seems that tere are compatibility issues
with groovy or something)
Le 14 janv. 08 à 12:47, Nikolas Kyriazopoulos Panagiotopoulos a écrit :
>> Could you possibly have an old iBATIS jar somewhere - maybe at the
>> common
>> or server level in Tomcat?
> Not anymore.
>
>>
>> What db and what version? If it's mysql, which type?
> MySql 5.0.45 (client) 5.0.32-Debian_7etch3-log(server), InnoDb
>
>> What does the jdbc URL look like? Are you passing any special
>> arguments
>> via the JDBC URL?
> jdbc:mysql://<an ip address here>/<database name here>
> no arguments to my knowledge (apart from normal username and
> password)
>
>> Are you using straight SQL in the SqlMaps or are you using stored
>> procedures?
> Straight SQL only
>
>> Are you seeing any locks in the db itself?
> No.
>
>> You could set the java.sql logging category to DEBUG and then you'd
>> be able
>> to trace which statements are blocking. This will generate a lot
>> of logfile
>> data, so be ready for it.
>
> Ok, we are configuring it at the moment. Stay tuned ;)
>
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Stéphane Hanser <s....@omegames.com>.
We also tried to use the last ibatis version from svn but it doesn't
work with our application (it seems that tere are compatibility issues
with groovy or something)
Le 14 janv. 08 à 12:47, Nikolas Kyriazopoulos Panagiotopoulos a écrit :
>> Could you possibly have an old iBATIS jar somewhere - maybe at the
>> common
>> or server level in Tomcat?
> Not anymore.
>
>>
>> What db and what version? If it's mysql, which type?
> MySql 5.0.45 (client) 5.0.32-Debian_7etch3-log(server), InnoDb
>
>> What does the jdbc URL look like? Are you passing any special
>> arguments
>> via the JDBC URL?
> jdbc:mysql://<an ip address here>/<database name here>
> no arguments to my knowledge (apart from normal username and
> password)
>
>> Are you using straight SQL in the SqlMaps or are you using stored
>> procedures?
> Straight SQL only
>
>> Are you seeing any locks in the db itself?
> No.
>
>> You could set the java.sql logging category to DEBUG and then you'd
>> be able
>> to trace which statements are blocking. This will generate a lot
>> of logfile
>> data, so be ready for it.
>
> Ok, we are configuring it at the moment. Stay tuned ;)
>
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com>.
> Could you possibly have an old iBATIS jar somewhere - maybe at the common
> or server level in Tomcat?
Not anymore.
>
> What db and what version? If it's mysql, which type?
MySql 5.0.45 (client) 5.0.32-Debian_7etch3-log(server), InnoDb
> What does the jdbc URL look like? Are you passing any special arguments
> via the JDBC URL?
jdbc:mysql://<an ip address here>/<database name here>
no arguments to my knowledge (apart from normal username and password)
> Are you using straight SQL in the SqlMaps or are you using stored
> procedures?
Straight SQL only
> Are you seeing any locks in the db itself?
No.
> You could set the java.sql logging category to DEBUG and then you'd be able
> to trace which statements are blocking. This will generate a lot of logfile
> data, so be ready for it.
Ok, we are configuring it at the moment. Stay tuned ;)
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Christopher Lamey <cl...@localmatters.com>.
I usually just turn it on for everything and let it rip...but then I have
large amounts of disk space. You could probably switch off the result set
stuff if you want.
On 1/15/08 5:48 AM, "Nikolas Kyriazopoulos Panagiotopoulos"
<ni...@gmail.com> wrote:
>> You could set the java.sql logging category to DEBUG and then you'd be able
>> to trace which statements are blocking. This will generate a lot of logfile
>> data, so be ready for it.
>
> To identify such issues we expect to see statements executed without
> having a corresponding result set? (I'm tempted to deactivate logging
> result sets as following, as they practically double the size of logs)
>
> log4j.logger.java.sql.Connection=debug
> log4j.logger.java.sql.Statement=debug
> #log4j.logger.java.sql.PreparedStatement=debug
> #log4j.logger.java.sql.ResultSet=debug
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Nikolas Kyriazopoulos Panagiotopoulos <ni...@gmail.com>.
> You could set the java.sql logging category to DEBUG and then you'd be able
> to trace which statements are blocking. This will generate a lot of logfile
> data, so be ready for it.
To identify such issues we expect to see statements executed without
having a corresponding result set? (I'm tempted to deactivate logging
result sets as following, as they practically double the size of logs)
log4j.logger.java.sql.Connection=debug
log4j.logger.java.sql.Statement=debug
#log4j.logger.java.sql.PreparedStatement=debug
#log4j.logger.java.sql.ResultSet=debug
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Chris Lamey <cl...@localmatters.com>.
Hmm...the default for Spring is to have no transaction management and Tomcat doesn't have any either...
Lots of people use iBATIS in high availability situations and don't hit this problem, so there's something with your setup or code that's causing the issue.
Could you possibly have an old iBATIS jar somewhere - maybe at the common or server level in Tomcat?
What db and what version? If it's mysql, which type?
What does the jdbc URL look like? Are you passing any special arguments via the JDBC URL?
Are you using straight SQL in the SqlMaps or are you using stored procedures?
Are you seeing any locks in the db itself?
You could set the java.sql logging category to DEBUG and then you'd be able to trace which statements are blocking. This will generate a lot of logfile data, so be ready for it.
-----Original Message-----
From: Stéphane Hanser [mailto:s.hanser@omegames.com]
Sent: Sat 1/12/2008 2:07 AM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Hello,
Yes the app is running on Tomcat 5.5
Here is the spring xml configuration and we aren't using transaction
anywhere in the app.
<!-- la source de donnéees DBCP -->
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="$
{jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<property name="maxActive" value="100"/>
<property name="maxIdle" value="30"/>
<property name="maxWait" value="10000"/>
</bean>
<!-- SqlMapClient -->
<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="configLocation">
<value>classpath:com/omegames/kilometres/dao/ibatis/maps/
sql-map-config-mysql.xml</value>
</property>
</bean>
Thanks,
Stéphane
Le 12 janv. 08 à 04:03, Chris Lamey a écrit :
> Hello,
>
> Is this running in an app server?
>
> How is the data source wired up to the SqlMapClientTemplate? Can we
> see the Spring xml doing this binding? Are you using declarative
> transactions anywhere in the app?
>
> Cheers,
> Chris
>
> -----Original Message-----
> From: Stéphane Hanser [mailto:s.hanser@omegames.com]
> Sent: Fri 1/11/2008 6:07 PM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> Hi everybody.
>
> I join this discussion because I'm working with Nikolas on this
> project and I'm fighting with this problem as well.
> Thank you very much for your answer. However I don't know yet how it
> will help us.
> Indeed we never use SqlMapClient but only SqlMapClientTemplate and we
> don't use transaction either.
>
> I agree with you when you says that we're out of connections but this
> is the point. The application behaves as if sessions weren't closed.
> We saw on th MySQL server that there was about as many connections as
> the maxActive parameter. All the connections were in sleep.
>
> We use commons-dbcp for our datasource (BasicDataSource).
>
> What do you think could bring to this kind of behavior?
>
> Thanks a lot
>
> Stéphane Hanser
>
>
> Le 11 janv. 08 à 22:39, Clinton Begin a écrit :
>
> > It's most likely that somewhere in your code you're not properly
> > ending a
> > transaction or closing a session.... Every single SqlMapClient usage
> > should
> > be wrapped with something like this (unless you're not using a
> > transaction
> > at all):
> >
> > try {
> > // start
> > // work
> > // commit
> > } finally {
> > // end
> > }
> >
> > Incidentally, if you want to grab the latest source from the trunk
> > and build
> > it (simple to do), I've completely removed all of the pooled
> > scopes. While
> > this likely won't solve your problem, the stack trace will likely
> > point you
> > to your datasouce and it will appear instead as though you're
> > running out of
> > connections (unless you're using our simpledatasource, in which case
> > the
> > connections will be forcefully reclaimed and you may never know
> > about the
> > problem).
> >
> > I'd do a thorough check of all SqlMapClient usages and make sure
> > they're in
> > try/finally blocks and that there is exactly the same number of
> > starts as
> > there are ends... (global text search can usually do this fairly
> > easily).
> >
> > Clinton
> >
> >
> > -----Original Message-----
> > From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com
> > ]
> > Sent: January-11-08 8:41 AM
> > To: user-java@ibatis.apache.org
> > Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
> >
> > [I resend this message because I hadn't confirmed the subscription
> to
> > the list before sending. Sorry for all those that might receive it
> > twice]
> >
> > Hello,
> > I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
> > into attention.
> > It seems that either an old problem is resurging (not really
> solved),
> > or that we have some configuration problems, so I would appreciate
> > your help.
> >
> > Every hour (approximately), suddenly, without a gradual increase in
> > thread count etc, a deadlock(?) suddenly rises the charge in our web
> > application and within seconds, the application is dead.
> > We tend to see threads like the following through jconsole when this
> > happens:
> >
> > Name: TP-Processor431
> > State: WAITING on java.lang.Object@253e7f
> > Total blocked: 4 388 Total waited: 248
> >
> > Stack trace:
> > java.lang.Object.wait(Native Method)
> > java.lang.Object.wait(Object.java:474)
> > com.ibatis.common.util.Throttle.increment(Throttle.java:70)
> > com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
> > orDelegate.java:930)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
> > a:51)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
> > lientImpl.java:258)
> >
> >
> > The database configuration is like this in our Spring 2.5.1
> > configuration files, for approximately 1000 connected users:
> >
> > <bean id="dataSource"
> > class="org.apache.commons.dbcp.BasicDataSource"
> > destroy-method="close">
> > [..]
> > <property name="maxActive" value="100"/>
> > <property name="maxIdle" value="30"/>
> > <property name="maxWait" value="10000"/>
> > </bean>
> >
> >
>
>
>
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Stéphane Hanser <s....@omegames.com>.
Hello,
Yes the app is running on Tomcat 5.5
Here is the spring xml configuration and we aren't using transaction
anywhere in the app.
<!-- la source de donnéees DBCP -->
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="$
{jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<property name="maxActive" value="100"/>
<property name="maxIdle" value="30"/>
<property name="maxWait" value="10000"/>
</bean>
<!-- SqlMapClient -->
<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="configLocation">
<value>classpath:com/omegames/kilometres/dao/ibatis/maps/
sql-map-config-mysql.xml</value>
</property>
</bean>
Thanks,
Stéphane
Le 12 janv. 08 à 04:03, Chris Lamey a écrit :
> Hello,
>
> Is this running in an app server?
>
> How is the data source wired up to the SqlMapClientTemplate? Can we
> see the Spring xml doing this binding? Are you using declarative
> transactions anywhere in the app?
>
> Cheers,
> Chris
>
> -----Original Message-----
> From: Stéphane Hanser [mailto:s.hanser@omegames.com]
> Sent: Fri 1/11/2008 6:07 PM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> Hi everybody.
>
> I join this discussion because I'm working with Nikolas on this
> project and I'm fighting with this problem as well.
> Thank you very much for your answer. However I don't know yet how it
> will help us.
> Indeed we never use SqlMapClient but only SqlMapClientTemplate and we
> don't use transaction either.
>
> I agree with you when you says that we're out of connections but this
> is the point. The application behaves as if sessions weren't closed.
> We saw on th MySQL server that there was about as many connections as
> the maxActive parameter. All the connections were in sleep.
>
> We use commons-dbcp for our datasource (BasicDataSource).
>
> What do you think could bring to this kind of behavior?
>
> Thanks a lot
>
> Stéphane Hanser
>
>
> Le 11 janv. 08 à 22:39, Clinton Begin a écrit :
>
> > It's most likely that somewhere in your code you're not properly
> > ending a
> > transaction or closing a session.... Every single SqlMapClient usage
> > should
> > be wrapped with something like this (unless you're not using a
> > transaction
> > at all):
> >
> > try {
> > // start
> > // work
> > // commit
> > } finally {
> > // end
> > }
> >
> > Incidentally, if you want to grab the latest source from the trunk
> > and build
> > it (simple to do), I've completely removed all of the pooled
> > scopes. While
> > this likely won't solve your problem, the stack trace will likely
> > point you
> > to your datasouce and it will appear instead as though you're
> > running out of
> > connections (unless you're using our simpledatasource, in which case
> > the
> > connections will be forcefully reclaimed and you may never know
> > about the
> > problem).
> >
> > I'd do a thorough check of all SqlMapClient usages and make sure
> > they're in
> > try/finally blocks and that there is exactly the same number of
> > starts as
> > there are ends... (global text search can usually do this fairly
> > easily).
> >
> > Clinton
> >
> >
> > -----Original Message-----
> > From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com
> > ]
> > Sent: January-11-08 8:41 AM
> > To: user-java@ibatis.apache.org
> > Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
> >
> > [I resend this message because I hadn't confirmed the subscription
> to
> > the list before sending. Sorry for all those that might receive it
> > twice]
> >
> > Hello,
> > I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
> > into attention.
> > It seems that either an old problem is resurging (not really
> solved),
> > or that we have some configuration problems, so I would appreciate
> > your help.
> >
> > Every hour (approximately), suddenly, without a gradual increase in
> > thread count etc, a deadlock(?) suddenly rises the charge in our web
> > application and within seconds, the application is dead.
> > We tend to see threads like the following through jconsole when this
> > happens:
> >
> > Name: TP-Processor431
> > State: WAITING on java.lang.Object@253e7f
> > Total blocked: 4 388 Total waited: 248
> >
> > Stack trace:
> > java.lang.Object.wait(Native Method)
> > java.lang.Object.wait(Object.java:474)
> > com.ibatis.common.util.Throttle.increment(Throttle.java:70)
> > com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
> > orDelegate.java:930)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
> > a:51)
> > com
> > .ibatis
> > .sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
> > lientImpl.java:258)
> >
> >
> > The database configuration is like this in our Spring 2.5.1
> > configuration files, for approximately 1000 connected users:
> >
> > <bean id="dataSource"
> > class="org.apache.commons.dbcp.BasicDataSource"
> > destroy-method="close">
> > [..]
> > <property name="maxActive" value="100"/>
> > <property name="maxIdle" value="30"/>
> > <property name="maxWait" value="10000"/>
> > </bean>
> >
> >
>
>
>
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Chris Lamey <cl...@localmatters.com>.
Hello,
Is this running in an app server?
How is the data source wired up to the SqlMapClientTemplate? Can we see the Spring xml doing this binding? Are you using declarative transactions anywhere in the app?
Cheers,
Chris
-----Original Message-----
From: Stéphane Hanser [mailto:s.hanser@omegames.com]
Sent: Fri 1/11/2008 6:07 PM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Hi everybody.
I join this discussion because I'm working with Nikolas on this
project and I'm fighting with this problem as well.
Thank you very much for your answer. However I don't know yet how it
will help us.
Indeed we never use SqlMapClient but only SqlMapClientTemplate and we
don't use transaction either.
I agree with you when you says that we're out of connections but this
is the point. The application behaves as if sessions weren't closed.
We saw on th MySQL server that there was about as many connections as
the maxActive parameter. All the connections were in sleep.
We use commons-dbcp for our datasource (BasicDataSource).
What do you think could bring to this kind of behavior?
Thanks a lot
Stéphane Hanser
Le 11 janv. 08 à 22:39, Clinton Begin a écrit :
> It's most likely that somewhere in your code you're not properly
> ending a
> transaction or closing a session.... Every single SqlMapClient usage
> should
> be wrapped with something like this (unless you're not using a
> transaction
> at all):
>
> try {
> // start
> // work
> // commit
> } finally {
> // end
> }
>
> Incidentally, if you want to grab the latest source from the trunk
> and build
> it (simple to do), I've completely removed all of the pooled
> scopes. While
> this likely won't solve your problem, the stack trace will likely
> point you
> to your datasouce and it will appear instead as though you're
> running out of
> connections (unless you're using our simpledatasource, in which case
> the
> connections will be forcefully reclaimed and you may never know
> about the
> problem).
>
> I'd do a thorough check of all SqlMapClient usages and make sure
> they're in
> try/finally blocks and that there is exactly the same number of
> starts as
> there are ends... (global text search can usually do this fairly
> easily).
>
> Clinton
>
>
> -----Original Message-----
> From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com
> ]
> Sent: January-11-08 8:41 AM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> [I resend this message because I hadn't confirmed the subscription to
> the list before sending. Sorry for all those that might receive it
> twice]
>
> Hello,
> I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
> into attention.
> It seems that either an old problem is resurging (not really solved),
> or that we have some configuration problems, so I would appreciate
> your help.
>
> Every hour (approximately), suddenly, without a gradual increase in
> thread count etc, a deadlock(?) suddenly rises the charge in our web
> application and within seconds, the application is dead.
> We tend to see threads like the following through jconsole when this
> happens:
>
> Name: TP-Processor431
> State: WAITING on java.lang.Object@253e7f
> Total blocked: 4 388 Total waited: 248
>
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:474)
> com.ibatis.common.util.Throttle.increment(Throttle.java:70)
> com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
> orDelegate.java:930)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
> a:51)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
> lientImpl.java:258)
>
>
> The database configuration is like this in our Spring 2.5.1
> configuration files, for approximately 1000 connected users:
>
> <bean id="dataSource"
> class="org.apache.commons.dbcp.BasicDataSource"
> destroy-method="close">
> [..]
> <property name="maxActive" value="100"/>
> <property name="maxIdle" value="30"/>
> <property name="maxWait" value="10000"/>
> </bean>
>
>
Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Stéphane Hanser <s....@omegames.com>.
Hi everybody.
I join this discussion because I'm working with Nikolas on this
project and I'm fighting with this problem as well.
Thank you very much for your answer. However I don't know yet how it
will help us.
Indeed we never use SqlMapClient but only SqlMapClientTemplate and we
don't use transaction either.
I agree with you when you says that we're out of connections but this
is the point. The application behaves as if sessions weren't closed.
We saw on th MySQL server that there was about as many connections as
the maxActive parameter. All the connections were in sleep.
We use commons-dbcp for our datasource (BasicDataSource).
What do you think could bring to this kind of behavior?
Thanks a lot
Stéphane Hanser
Le 11 janv. 08 à 22:39, Clinton Begin a écrit :
> It's most likely that somewhere in your code you're not properly
> ending a
> transaction or closing a session.... Every single SqlMapClient usage
> should
> be wrapped with something like this (unless you're not using a
> transaction
> at all):
>
> try {
> // start
> // work
> // commit
> } finally {
> // end
> }
>
> Incidentally, if you want to grab the latest source from the trunk
> and build
> it (simple to do), I've completely removed all of the pooled
> scopes. While
> this likely won't solve your problem, the stack trace will likely
> point you
> to your datasouce and it will appear instead as though you're
> running out of
> connections (unless you're using our simpledatasource, in which case
> the
> connections will be forcefully reclaimed and you may never know
> about the
> problem).
>
> I'd do a thorough check of all SqlMapClient usages and make sure
> they're in
> try/finally blocks and that there is exactly the same number of
> starts as
> there are ends... (global text search can usually do this fairly
> easily).
>
> Clinton
>
>
> -----Original Message-----
> From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com
> ]
> Sent: January-11-08 8:41 AM
> To: user-java@ibatis.apache.org
> Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
>
> [I resend this message because I hadn't confirmed the subscription to
> the list before sending. Sorry for all those that might receive it
> twice]
>
> Hello,
> I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
> into attention.
> It seems that either an old problem is resurging (not really solved),
> or that we have some configuration problems, so I would appreciate
> your help.
>
> Every hour (approximately), suddenly, without a gradual increase in
> thread count etc, a deadlock(?) suddenly rises the charge in our web
> application and within seconds, the application is dead.
> We tend to see threads like the following through jconsole when this
> happens:
>
> Name: TP-Processor431
> State: WAITING on java.lang.Object@253e7f
> Total blocked: 4 388 Total waited: 248
>
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:474)
> com.ibatis.common.util.Throttle.increment(Throttle.java:70)
> com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
> orDelegate.java:930)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
> a:51)
> com
> .ibatis
> .sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
> lientImpl.java:258)
>
>
> The database configuration is like this in our Spring 2.5.1
> configuration files, for approximately 1000 connected users:
>
> <bean id="dataSource"
> class="org.apache.commons.dbcp.BasicDataSource"
> destroy-method="close">
> [..]
> <property name="maxActive" value="100"/>
> <property name="maxIdle" value="30"/>
> <property name="maxWait" value="10000"/>
> </bean>
>
>
RE: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
Posted by Clinton Begin <cl...@gmail.com>.
It's most likely that somewhere in your code you're not properly ending a
transaction or closing a session.... Every single SqlMapClient usage should
be wrapped with something like this (unless you're not using a transaction
at all):
try {
// start
// work
// commit
} finally {
// end
}
Incidentally, if you want to grab the latest source from the trunk and build
it (simple to do), I've completely removed all of the pooled scopes. While
this likely won't solve your problem, the stack trace will likely point you
to your datasouce and it will appear instead as though you're running out of
connections (unless you're using our simpledatasource, in which case the
connections will be forcefully reclaimed and you may never know about the
problem).
I'd do a thorough check of all SqlMapClient usages and make sure they're in
try/finally blocks and that there is exactly the same number of starts as
there are ends... (global text search can usually do this fairly easily).
Clinton
-----Original Message-----
From: Nikolas Kyriazopoulos Panagiotopoulos [mailto:nikolaskp@gmail.com]
Sent: January-11-08 8:41 AM
To: user-java@ibatis.apache.org
Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3)
[I resend this message because I hadn't confirmed the subscription to
the list before sending. Sorry for all those that might receive it
twice]
Hello,
I would like to bring this: https://issues.apache.org/jira/browse/IBATIS-249
into attention.
It seems that either an old problem is resurging (not really solved),
or that we have some configuration problems, so I would appreciate
your help.
Every hour (approximately), suddenly, without a gradual increase in
thread count etc, a deadlock(?) suddenly rises the charge in our web
application and within seconds, the application is dead.
We tend to see threads like the following through jconsole when this
happens:
Name: TP-Processor431
State: WAITING on java.lang.Object@253e7f
Total blocked: 4 388 Total waited: 248
Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474)
com.ibatis.common.util.Throttle.increment(Throttle.java:70)
com.ibatis.common.util.ThrottledPool.pop(ThrottledPool.java:57)
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.popSession(SqlMapExecut
orDelegate.java:930)
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.<init>(SqlMapSessionImpl.jav
a:51)
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession(SqlMapC
lientImpl.java:258)
The database configuration is like this in our Spring 2.5.1
configuration files, for approximately 1000 connected users:
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
[..]
<property name="maxActive" value="100"/>
<property name="maxIdle" value="30"/>
<property name="maxWait" value="10000"/>
</bean>