Re: DBCP Pool not context-specific?

2006-11-01 Thread Christopher Schultz
John,

John Gorkos wrote:
 I use per-context JNDI handles to 
 the same Postgres database for multiple apps running inside tomcat.  Each 
 context.xml sets up connection limits, max idle, etc, slightly differently.

You said per-context JNDI handles, not per-context JNDI DataSources.
Where are you defining your datasource? In context.xml, or in server.xml
with additional, per-context configuration in context.xml?

Can you show us the configuration for your JNDI DataSource, including
the location in whatever file you use? For instance, if you use
server.xml, /where/ you do put the Resource element?

-chris



signature.asc
Description: OpenPGP digital signature


Re: DBCP Pool not context-specific?

2006-11-01 Thread John Gorkos
On Wednesday 01 November 2006 11:58, Christopher Schultz wrote:
 John,

 John Gorkos wrote:
  I use per-context JNDI handles to
  the same Postgres database for multiple apps running inside tomcat.  Each
  context.xml sets up connection limits, max idle, etc, slightly

 differently.

 You said per-context JNDI handles, not per-context JNDI DataSources.
 Where are you defining your datasource? In context.xml, or in server.xml
 with additional, per-context configuration in context.xml?

 Can you show us the configuration for your JNDI DataSource, including
 the location in whatever file you use? For instance, if you use
 server.xml, /where/ you do put the Resource element?

 -chris

Chris - thanks for the quick response.  We've just moved to tomcat 5.5.  I'm 
using a per-app context XML that looks like this:
?xml version='1.0' encoding='utf-8'?
Context crossContext=true debug=10 docBase=AMDSTools
path=/AMDSTools reloadable=true antiJARLocking=true 
antiResourceLocking=true
Logger className=org.apache.catalina.logger.FileLogger 
prefix=localhost_log. suffix=.txt timestamp=true/
Resource name=jdbc/psql auth=Container
type=javax.sql.DataSource username=amds password=XxXxXx
factory=org.apache.commons.dbcp.BasicDataSourceFactory
driverClassName=org.postgresql.Driver 
url=jdbc:postgresql://127.0.0.1:5432/amds
removeAbandoned=true removeAbandonedTimeout=2 
logAbandoned=true
maxActive=60 maxIdle=30 maxWait=5000 
poolPreparedStatements=true/
/Context


My server.xml is untouched from the default distribution of tomcat 5.5.

And yes, I think the term I was searching for was per-context datasources.

John Gorkos


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: DBCP Pool not context-specific?

2006-11-01 Thread Christopher Schultz
John,

John Gorkos wrote:
 On Wednesday 01 November 2006 11:58, Christopher Schultz wrote:
 John Gorkos wrote:
 I use per-context JNDI handles to
 the same Postgres database for multiple apps running inside tomcat.  Each
 context.xml sets up connection limits, max idle, etc, slightly
 differently.

 You said per-context JNDI handles, not per-context JNDI DataSources.
 Where are you defining your datasource? In context.xml, or in server.xml
 with additional, per-context configuration in context.xml?

 Can you show us the configuration for your JNDI DataSource, including
 the location in whatever file you use? For instance, if you use
 server.xml, /where/ you do put the Resource element?

 -chris
 
 Chris - thanks for the quick response.  We've just moved to tomcat 5.5.  I'm 
 using a per-app context XML that looks like this:

 Context crossContext=true debug=10 docBase=AMDSTools

It looks like you have your resource defined (correctly) in context.xml,
which is what I would expect do to for context isolation of such a
DataSource.

I wonder if crossContext=true muddles this at all? My understanding is
that crossContext=true basically changes the cookie path from /myapp
to /, and allows a globally-managed session instead of per-context
sessions. I'm grasping at straws, here, since your config at least looks
plausible.

 Resource name=jdbc/psql auth=Container

Any chance that your JNDI names are colliding with other apps? I dunno
if Tomcat provides JNDI isolation for contexts (although it wouldn't
make any sense not to provide that).

If none of these turns out to be the problem, you may have to re-post
your question. Often, folks on the list assume that a continued
conversation means that the problem is getting solved by someone else,
and might not read it. If you don't get a reply for a day or so, re-post
with some of the extra information you've provided to me.

I'm not an expert when it comes to the subtleties of Tomcat and context
isolation. Who knows... maybe you even found a bug.

-chris




signature.asc
Description: OpenPGP digital signature


Re: DBCP Pool not context-specific?

2006-11-01 Thread John Gorkos
On Wednesday 01 November 2006 12:19, Christopher Schultz wrote:
snip
  using a per-app context XML that looks like this:
 
  Context crossContext=true debug=10 docBase=AMDSTools

 It looks like you have your resource defined (correctly) in context.xml,
 which is what I would expect do to for context isolation of such a
 DataSource.

 I wonder if crossContext=true muddles this at all? My understanding is
 that crossContext=true basically changes the cookie path from /myapp
 to /, and allows a globally-managed session instead of per-context
 sessions. I'm grasping at straws, here, since your config at least looks
 plausible.

  Resource name=jdbc/psql auth=Container

 Any chance that your JNDI names are colliding with other apps? I dunno
 if Tomcat provides JNDI isolation for contexts (although it wouldn't
 make any sense not to provide that).
Indeed, they ALL use this same resource name...  



 If none of these turns out to be the problem, you may have to re-post
 your question. Often, folks on the list assume that a continued
 conversation means that the problem is getting solved by someone else,
 and might not read it. If you don't get a reply for a day or so, re-post
 with some of the extra information you've provided to me.

 I'm not an expert when it comes to the subtleties of Tomcat and context
 isolation. Who knows... maybe you even found a bug.

 -chris
thanks for your help.  I think I'll try changing resource names.  A name that 
includes the appName would help prevent collisions, especially on a shared 
server, where I don't own all the apps.

John Gorkos

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: DBCP Pool not context-specific?

2006-11-01 Thread Pid
if, (for whatever reason), one webapp isn't releasing connections, but
is able to keep creating them, then eventually you'll run out of
available connections at the DB end, no?

i'd expend effort determining why the app isn't releasing the
connections, as that's the real problem.



John Gorkos wrote:
 On Wednesday 01 November 2006 12:19, Christopher Schultz wrote:
 snip
 using a per-app context XML that looks like this:

 Context crossContext=true debug=10 docBase=AMDSTools
 It looks like you have your resource defined (correctly) in context.xml,
 which is what I would expect do to for context isolation of such a
 DataSource.

 I wonder if crossContext=true muddles this at all? My understanding is
 that crossContext=true basically changes the cookie path from /myapp
 to /, and allows a globally-managed session instead of per-context
 sessions. I'm grasping at straws, here, since your config at least looks
 plausible.

 Resource name=jdbc/psql auth=Container
 Any chance that your JNDI names are colliding with other apps? I dunno
 if Tomcat provides JNDI isolation for contexts (although it wouldn't
 make any sense not to provide that).
 Indeed, they ALL use this same resource name...  
 
 
 If none of these turns out to be the problem, you may have to re-post
 your question. Often, folks on the list assume that a continued
 conversation means that the problem is getting solved by someone else,
 and might not read it. If you don't get a reply for a day or so, re-post
 with some of the extra information you've provided to me.

 I'm not an expert when it comes to the subtleties of Tomcat and context
 isolation. Who knows... maybe you even found a bug.

 -chris
 thanks for your help.  I think I'll try changing resource names.  A name that 
 includes the appName would help prevent collisions, especially on a shared 
 server, where I don't own all the apps.
 
 John Gorkos
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: DBCP Pool not context-specific?

2006-11-01 Thread John Gorkos
On Wednesday 01 November 2006 13:39, Pid wrote:
 if, (for whatever reason), one webapp isn't releasing connections, but
 is able to keep creating them, then eventually you'll run out of
 available connections at the DB end, no?
Yes, but the database was set up to allow 500 connections, and the pool was 
running dry after 50.  The disturbing part is that the pool was running dry 
in one context and causing other contexts in the same VM to throw 
PoolExhausted exceptions.  I was hoping for a higher degree of seperation 
between contexts than what I got.

 i'd expend effort determining why the app isn't releasing the
 connections, as that's the real problem.

Done.  We followed the JNDI datasource reccomendations on the Tomcat web page 
and got bit.  It was my fault for cutting and pasting so verbatim.  The app 
works and releases correctly now.

John Gorkos


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]