proxool-developer — Developer's discussion list

[Proxool-developer] Spurious connections caused by Prototyper's apparently wrong connectionCount

[Hrvoje N. <hn...@xe...>]

We're having a problem deploying Proxool 0.8.3 with Oracle.  The
relevant settings are:

jdbc-0.proxool.maximum-connection-count 30
jdbc-0.proxool.minimum-connection-count 2
jdbc-0.proxool.house-keeping-sleep-time 60000
jdbc-0.proxool.house-keeping-test-sql select * from dual
jdbc-0.proxool.test-before-use true
jdbc-0.proxool.maximum-active-time 240000
jdbc-0.proxool.maximum-connection-lifetime 1800000
...

So proxool should maintain no less than 2 and no more than 30
connections to the database.  But, over time, it appears that proxool
opens more connections, eventually exhausting Oracle's
SESSIONS_PER_USER limit.  All the connections are usable and the
additional ones are opened at times when there there are other usable
connections available.  For example, when creating the 33rd
connection, Proxool's log contains:

2005-09-27 01:36:57 DEBUG [ConnectionPool] [Thread-18]: 1003445 -000257 (04/32/00) - Connection #1646 tested: OK
2005-09-27 01:36:57 DEBUG [chatdate] [Prototyper]: 1003446 -000257 (04/33/00) - Connection #1666 created to achieve minimum of 2 = AVAILABLE

04/32/00 shows that ConnectionPool is aware that it has a total of 32
connections, 28 of which are available, and yet the Prototyper thinks
it has less than two open connections and is trying to open more to
make up for the perceived shortage.  Examining established connections
with netstat shows that ConnectionPool's numbers are correct.

A possible cause for this problem was outlined by Peter Radics in his
message from Jan 11th, http://tinyurl.com/7eb77/.  He noticed that
each time HouseKeeper sweeps a connection that has been active for too
long, connectionCount gets decremented twice.  However, no one
responded to that message and I don't know if this problem has been
fixed in the development sources.  I'm reluctant to apply his patch
unchanged because it feels like a kludge and because the last part
contains an increment I don't understand.

Another problem I noticed with the Prototyper code is that it lacks
synchronization when decrementing connectionCount.  That cannot be
good, although it is probably not the cause of this particular
problem.

Are you aware of a fix or a workaround for this?  Thanks for your
help.

Re: [Proxool-developer] Mercifully killing all current connections because of definition changes

[Pratik M. <pr...@ar...>]

Hi Bill,
Thanks for your help.
the message if I am right means that proxool has created connection =
#0192 and destroyed then created connection #193 and destroyed.
This continues almost every few seconds my thread is requesting the =
connection.
Here is my code to get Connection.

Connection cn=3D null;
  ResourceBundle r =3D ResourceBundle.getBundle("proxoool");
  try{
   Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
      String cnStrg =3D "proxool.sms:" +r.getString("driver")+":"+ =
r.getString("constring") ;
      cn =3DDriverManager.getConnection(cnStrg , =
r.getString("user"),r.getString("password"));

  }
  catch(Exception e){
   Smslog.append(e);
  }
  return cn;

I have not change the resourceBundle proxool. But I did change some =
other ResourceBundle .

Thanks in Advance,

Best Regards,
Pratik Machchar
  ----- Original Message -----=20
  From: Bill Horsman=20
  To: pro...@li...=20
  Sent: Friday, September 23, 2005 11:56 PM
  Subject: Re: [Proxool-developer] Mercifully killing all current =
connections because of definition changes


  Hi Pratik,

  Pratik Machchar wrote:

  > Proxool keeps on opening connection and closing the same.
  [snip]
  > Mercifully killing all current connections because of definition =
changes
  > DEBUG - 000188 -000004 (00/00/00) - #0192 removed because definition =
has=20
  > changed.
  > DEBUG - 000188 -000004 (01/01/00) - Connection #193 created on =
demand =3D=20
  > ACTIVE
  > DEBUG - Redefining definition

  I'm not sure how long you have been running the app but 192+ =
connections=20
  sounds like a lot. The "because of definition changes" bit of the log=20
  leads me to believe that you are redefining the pool frequently which=20
  I'm assuming isn't your intention.

  The most likely cause is that you are giving the full URl each time =
you=20
  request a connection. This is fine, but I wonder whether you have two=20
  different URLs? If they both share the same pool alias then the same=20
  pool will constantly be redefined.

  I suggest either:

  a) you check that the URL you are using is the same for each request, =
or

  b) you configure the pool (see the doc for the various ways you can do =

  this) and just use the simpler URL that includes just the alias. Like=20
  this: "proxool.aruhat". See=20
  http://proxool.sourceforge.net/quickStart.html for more information.

  Let the list know how you get on, please.

  Cheers,
  Bill


  -------------------------------------------------------
  SF.Net email is sponsored by:
  Tame your development challenges with Apache's Geronimo App Server.=20
  Download it for free - -and be entered to win a 42" plasma tv or your =
very
  own Sony(tm)PSP.  Click here to play: =
http://sourceforge.net/geronimo.php
  _______________________________________________
  Proxool-developer mailing list
  Pro...@li...
  https://lists.sourceforge.net/lists/listinfo/proxool-developer

Re: [Proxool-developer] Mercifully killing all current connections because of definition changes

[Bill H. <bi...@lo...>]

Hi Pratik,

Pratik Machchar wrote:

> Proxool keeps on opening connection and closing the same.
[snip]
> Mercifully killing all current connections because of definition changes
> DEBUG - 000188 -000004 (00/00/00) - #0192 removed because definition has 
> changed.
> DEBUG - 000188 -000004 (01/01/00) - Connection #193 created on demand = 
> ACTIVE
> DEBUG - Redefining definition

I'm not sure how long you have been running the app but 192+ connections 
sounds like a lot. The "because of definition changes" bit of the log 
leads me to believe that you are redefining the pool frequently which 
I'm assuming isn't your intention.

The most likely cause is that you are giving the full URl each time you 
request a connection. This is fine, but I wonder whether you have two 
different URLs? If they both share the same pool alias then the same 
pool will constantly be redefined.

I suggest either:

a) you check that the URL you are using is the same for each request, or

b) you configure the pool (see the doc for the various ways you can do 
this) and just use the simpler URL that includes just the alias. Like 
this: "proxool.aruhat". See 
http://proxool.sourceforge.net/quickStart.html for more information.

Let the list know how you get on, please.

Cheers,
Bill

[Proxool-developer] Mercifully killing all current connections because of definition changes

[Pratik M. <pr...@ar...>]

Hi All,
I have just started using proxool.
and facing strange problem on my webserver.

Proxool keeps on opening connection and closing the same.=20

and I receive this final message for each connection.
I did call shutdown() method of facade but even after that this same =
thing starts.

My server finally gives  out of memory message can anyone pl. help me on =
this.
I am using latest proxool and tomcat 4.

Billow is the message.

Best Regards,
Pratik Machchar

Mercifully killing all current connections because of definition changes
DEBUG - 000188 -000004 (00/00/00) - #0192 removed because definition has =
changed.
DEBUG - 000188 -000004 (01/01/00) - Connection #193 created on demand =
=3D ACTIVE
DEBUG - Redefining definition
DEBUG - Recognised proxool property: =
proxool.driver=3Dcom.mysql.jdbc.Driver
DEBUG - Recognised proxool property: =
proxool.url=3Djdbc:mysql://localhost/aruhat?user=3Daruhat&password=3Daat3=
21
DEBUG - Delegating property to driver: user=3Droot
DEBUG - Delegating property to driver: password=3D********

[Proxool-developer] Re: 0.9.0 Schedule

[Mike W. <mi...@ho...>]

Hi Bill,
 
Doing some more testing on the latest code I realized I was getting
exceptions when debugging my Weblogic project from Eclipse. Using your
proxool snapshot I am getting
 
  java.lang.NoClassDefFoundError: org/logicalcobwebs/cglib/proxy/Factory
 
from inside the Proxool code.
 
The reason seems to be when the cglib code is creating the proxy instance
for the Oracle connection, it is using the wrong classloader. Scenario:

- ReflectUtils.defineClass() wants to know the classloader to use. 

- getClassLoader() returns the value of getDefaultClassLoader(). 

- getDefaultClassLoader() fetches the classloader from the first 
  interface (as there is no superclass), see code:
    protected ClassLoader getDefaultClassLoader() {
        if (superclass != null) {
            return superclass.getClassLoader();
        } else if (interfaces != null) {
            return interfaces[0].getClassLoader();
        } else {
            return null;
        }
    }
  During my test runs it has sometimes been copied from 
  oracle.sql.BfileDBAccess and sometimes from 
  oracle.sql.internal.OracleConnection and they both belong to the 
  "application global" sun.misc.Launcher$AppClassLoader. 

- Using this classloader, the JVM will fail in locating the proxool 
  Factory interface (to be implemented by the gclib proxy instance) 
  as proxool.jar is only reachable from the webapp's own classloader.

If I understand it correctly, the 0.8.3 version of proxool always specified
a proxool defined superclass for proxy instances. This meant proxy instances
would be created with the same classloader as was used to load proxool
(because of the code in getDefaultClassLoader), and proxool classes would
then always be found through this loader.

So, to summarize, the old version of proxool was basing its classloader
choice for proxies on a proxool class (Proxy?) while the new version will
use the classloader of the first implemented interface. And in my scenario
these point to different loaders.
I think the new proxool code should be updated to make a safer choice on
what classloader to choose for its proxies. It would probably be safer to
use the classloader used to load proxool as is in practice done in the old
version.

I think many users with application servers will stumble on this bug so it
should be thought through...
 
See stacktrace below.
 
Actually, I was at first puzzled by the Oracle interfaces (and
T4CConnection) belonging to the global classloader despite that we are
supplying the Oracle JDBC driver in the webapp's WEB-INF/lib. This happens
with both proxool 0.8.3 and 0.8.9.

I found out that the Oracle drivers bundled with Weblogic are always visible
in the application classpath and take precedence over the ones in the webapp
(even though we are not using Weblogic's connection pools), and are
therefore defined on the global application classloader.
It is possible to change this precedence behaviour by setting 
  <prefer-web-inf-classes>true</prefer-web-inf-classes>
in weblogic.xml, but this has other drawbacks.

Best regards
Mike
 
Exception: org.logicalcobwebs.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException-->null
[0]
org.logicalcobwebs.cglib.core.AbstractClassGenerator.create(AbstractClassGen
erator.java:206)
[1] org.logicalcobwebs.cglib.proxy.Enhancer.createHelper(Enhancer.java:331)
[2] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:247)
[3] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:407)
[4]
org.logicalcobwebs.proxool.ProxyFactory.getWrappedConnection(ProxyFactory.ja
va:60)
[5]
org.logicalcobwebs.proxool.ConnectionPool.getConnection(ConnectionPool.java:
268)
[6] org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:89)
[7] java.sql.DriverManager.getConnection(DriverManager.java:512)
[8] java.sql.DriverManager.getConnection(DriverManager.java:193)
[9]
net.sf.hibernate.connection.ProxoolConnectionProvider.getConnection(ProxoolC
onnectionProvider.java:51)
[10]
net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
[11]
net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1172)
[12]
net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:80
3)
<snip>
[20]
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces
sor.java:421)
[21]
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
[22] org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
[23] org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
[24] javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
[25] javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[26]
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(Servle
tStubImpl.java:996)
[27]
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:419)
[28] weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
[29]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
[30] HibernateFilter.doFilter(HibernateFilter.java:107)
[31]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
[32]
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(W
ebAppServletContext.java:6458)
[33]
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubjec
t.java:321)
[34]
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
[35]
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:3661)
[36]
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2630)
[37] weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
[38] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Cause: java.lang.reflect.InvocationTargetException
Cause [0] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Cause [1]
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
Cause [2]
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
java:25)
Cause [3] java.lang.reflect.Method.invoke(Method.java:324)
Cause [4]
org.logicalcobwebs.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:373
)
Cause [5]
org.logicalcobwebs.cglib.core.AbstractClassGenerator.create(AbstractClassGen
erator.java:193)
Cause [6]
org.logicalcobwebs.cglib.proxy.Enhancer.createHelper(Enhancer.java:331)
Cause [7] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:247)
Cause [8] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:407)
Cause [9]
org.logicalcobwebs.proxool.ProxyFactory.getWrappedConnection(ProxyFactory.ja
va:60)
Cause [10]
org.logicalcobwebs.proxool.ConnectionPool.getConnection(ConnectionPool.java:
268)
Cause [11]
org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:89)
Cause [12] java.sql.DriverManager.getConnection(DriverManager.java:512)
Cause [13] java.sql.DriverManager.getConnection(DriverManager.java:193)
Cause [14]
net.sf.hibernate.connection.ProxoolConnectionProvider.getConnection(ProxoolC
onnectionProvider.java:51)
Cause [15]
net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
Cause [16]
net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1172)
Cause [17]
net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:80
3)
<snip>
Cause [25]
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces
sor.java:421)
Cause [26]
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
Cause [27]
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
Cause [28]
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
Cause [29] javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
Cause [30] javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
Cause [31]
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(Servle
tStubImpl.java:996)
Cause [32]
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:419)
Cause [33] weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
Cause [34]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
Cause [35] HibernateFilter.doFilter(HibernateFilter.java:107)
Cause [36]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
Cause [37]
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(W
ebAppServletContext.java:6458)
Cause [38]
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubjec
t.java:321)
Cause [39]
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
Cause [40]
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:3661)
Cause [41]
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2630)
Cause [42] weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
Cause [43] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Cause: java.lang.NoClassDefFoundError:
org/logicalcobwebs/cglib/proxy/Factory
Cause [0] java.lang.ClassLoader.defineClass0(Native Method)
Cause [1] java.lang.ClassLoader.defineClass(ClassLoader.java:539)
Cause [2] java.lang.ClassLoader.defineClass(ClassLoader.java:382)
Cause [3] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Cause [4]
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
Cause [5]
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
java:25)
Cause [6] java.lang.reflect.Method.invoke(Method.java:324)
Cause [7]
org.logicalcobwebs.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:373
)
Cause [8]
org.logicalcobwebs.cglib.core.AbstractClassGenerator.create(AbstractClassGen
erator.java:193)
Cause [9]
org.logicalcobwebs.cglib.proxy.Enhancer.createHelper(Enhancer.java:331)
Cause [10] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:247)
Cause [11] org.logicalcobwebs.cglib.proxy.Enhancer.create(Enhancer.java:407)
Cause [12]
org.logicalcobwebs.proxool.ProxyFactory.getWrappedConnection(ProxyFactory.ja
va:60)
Cause [13]
org.logicalcobwebs.proxool.ConnectionPool.getConnection(ConnectionPool.java:
268)
Cause [14]
org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:89)
Cause [15] java.sql.DriverManager.getConnection(DriverManager.java:512)
Cause [16] java.sql.DriverManager.getConnection(DriverManager.java:193)
Cause [17]
net.sf.hibernate.connection.ProxoolConnectionProvider.getConnection(ProxoolC
onnectionProvider.java:51)
Cause [18]
net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
Cause [19]
net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1172)
Cause [20]
net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:80
3)
<snip>
Cause [28]
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces
sor.java:421)
Cause [29]
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
Cause [30]
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
Cause [31]
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
Cause [32] javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
Cause [33] javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
Cause [34]
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(Servle
tStubImpl.java:996)
Cause [35]
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:419)
Cause [36] weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
Cause [37]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
Cause [38] HibernateFilter.doFilter(HibernateFilter.java:107)
Cause [39]
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
Cause [40]
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(W
ebAppServletContext.java:6458)
Cause [41]
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubjec
t.java:321)
Cause [42]
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
Cause [43]
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:3661)
Cause [44]
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2630)
Cause [45] weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
Cause [46] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

Re: [Proxool-developer] Re: 0.9.0 Schedule

[Bill H. <arc...@gm...>]

Hi Mike,

On 8/29/05, Mike Wilson <mi...@ho...> wrote:=20

I'm curious whether bug 923767 "HouseKeeper thread continues after
> ProxoolFacade.shutdown(0)" will be fixed in 0.9.0 ?
> (This is something of a showstopper for our project.)



I'm curious too. It should be. Would you mind trying it? The latest code=20
from CVS is of release candidate quality.

-
Bill

[Proxool-developer] Re: 0.9.0 Schedule

[Mike W. <mi...@ho...>]

I'm curious whether bug 923767 "HouseKeeper thread continues after
ProxoolFacade.shutdown(0)" will be fixed in 0.9.0 ?
(This is something of a showstopper for our project.)
Cheers
Mike

Re: [Proxool-developer] Temporary creation of connections when maximum connection has been reached

[Bill H. <bi...@lo...>]

Hi Diarmuid,

Diarmuid McDonald wrote:

> I think the Oracle use of Dynamic scheme is related to performance on
>  heavy load applications.

Creating new connections afresh when under heavy load would seem to be a
bad idea.

> I am not 100% certain how it makes a difference, but Im sure Oracle 
> have their reasons.

They may do. They may not. It might just something that someone put in a
long time ago without thinking it through. Having said that, as long as
it was turned off by default I don't see it causing any problems.

> I just have another quick question about the
> maximum-connection-lifetime. Is there any logic in proxool, that if a
>  heavy load application creates connections at the same time on 
> startup, does it stagger the refreshing of the connections in the 
> pool, to ensure that there is not a spike in the delay time of the 
> application.

No there isn't. Connections would tend to be created in waves as you 
describe. It would gradually become more even though. I like the idea of 
solving that. How about:

1. Never expire more than 25% of the connections in any one sweep unless 
we have too (see rule 2).

2. Force the expiry of a connection if delaying it until the next sweep 
will make it more than 1.25 older than the expire time regardless of how 
many connections you have already expired in that sweep.

I think we can improve on that algorithm too. If the lifetime is 4 hours 
then we could happily delay an expiry for 10 minutes I would think. I 
think this might be a new configuration property called expiry-leniency 
or something.

So, for example, if you have 10 connections all due for expiry after 30 
minutes they would be expired in four goes, 30 seconds apart.

Note that we aren't breaking a contract by delaying the expiry. At 
least, no more so than we do already. We only agree to expire them soon 
after their maximum-connection-lifetime. In the existing code, under the 
default configuration, the connections can last up to 30 seconds or so 
longer than the maximum-connection-lifetime.

-
Bill

RE: [Proxool-developer] Temporary creation of connections when maximum connection has been reached

[Diarmuid M. <Dia...@Tr...>]

SGkgQmlsbCwNCg0KSSBzaG91bGQgaGF2ZSBnaXZlbiBtb3JlIG9mIGEgYmFja2dyb3VuZCwg
bXkgYXBvbG9naWVzLiBDdXJyZW50bHkgd2UgYXJlIHVzaW5nIE9yYWNsZSBjb25uZWN0aW9u
IHBvb2xpbmcsIGhvd2V2ZXIgd2Ugd2FudCB0byBjaGFuZ2UgdG8gcHJveG9vbC4gDQoNCk9y
YWNsZSBzdXBwb3J0cyB0aHJlZSBjb25uZWN0aW9uIGNhY2hlIHNjaGVtZXMuIFlvdSBjYW4g
dXNlIHRoZXNlIHNjaGVtZXMgaW4gc2l0dWF0aW9ucyB3aGVyZSAoMSkgdGhlIGFwcGxpY2F0
aW9uIGhhcyByZXF1ZXN0ZWQgYSBjb25uZWN0aW9uLCAoMikgYWxsIGV4aXN0aW5nIHBvb2xl
ZCBjb25uZWN0aW9ucyBhcmUgaW4gdXNlLCBhbmQgKDMpIHRoZSBtYXhpbXVtIG51bWJlciBv
ZiBwb29sZWQgY29ubmVjdGlvbnMgaW4gdGhlIGNhY2hlIGhhdmUgYmVlbiByZWFjaGVkLg0K
DQoxKSBkeW5hbWljDQoNCiAgICAgIEluIHRoaXMgZGVmYXVsdCBzY2hlbWUsIHlvdSBjYW4g
Y3JlYXRlIG5ldyBwb29sZWQgY29ubmVjdGlvbnMgYWJvdmUgYW5kIGJleW9uZCB0aGUgbWF4
aW11bSBsaW1pdCwgYnV0IGVhY2ggb25lIGlzIGF1dG9tYXRpY2FsbHkgY2xvc2VkIGFuZCBm
cmVlZCBhcyBzb29uIGFzIHRoZSBsb2dpY2FsIGNvbm5lY3Rpb24gaW5zdGFuY2UgdGhhdCBp
dCBwcm92aWRlZCBpcyBubyBsb25nZXIgaW4gdXNlLiAoQXMgb3Bwb3NlZCB0byB0aGUgbm9y
bWFsIHNjZW5hcmlvIHdoZW4gYSBwb29sZWQgY29ubmVjdGlvbiBpbnN0YW5jZSBpcyBmaW5p
c2hlZCBiZWluZyB1c2VkLCB3aGVyZSBpdCBpcyByZXR1cm5lZCB0byB0aGUgYXZhaWxhYmxl
IGNhY2hlLikNCg0KMikgZml4ZWQgd2l0aCBubyB3YWl0DQoNCiAgICAgIEluIHRoaXMgc2No
ZW1lLCB0aGUgbWF4aW11bSBsaW1pdCBjYW5ub3QgYmUgZXhjZWVkZWQuIFJlcXVlc3RzIGZv
ciBjb25uZWN0aW9ucyB3aGVuIHRoZSBtYXhpbXVtIGhhcyBhbHJlYWR5IGJlZW4gcmVhY2hl
ZCB3aWxsIHJldHVybiBudWxsLg0KDQozKSBmaXhlZCB3YWl0DQoNCiAgICAgIFNhbWUgYXMg
dGhlICJmaXhlZCB3aXRoIG5vIHdhaXQiIHNjaGVtZSBleGNlcHQgdGhhdCBhIHJlcXVlc3Qg
Zm9yIGEgbmV3IGNvbm5lY3Rpb24gd2lsbCB3YWl0IGlmIHRoZSBsaW1pdCBmb3IgdGhlIG51
bWJlciBvZiBjb25uZWN0aW9ucyBoYXMgYmVlbiByZWFjaGVkLiBJbiB0aGlzIGNhc2UsIHRo
ZSBjb25uZWN0aW9uIHJlcXVlc3Qgd2FpdHMgdW50aWwgYW5vdGhlciBjbGllbnQgcmVsZWFz
ZXMgYSBjb25uZWN0aW9uLiANCg0KU28gYmVmb3JlIHdlIGNhbiBzd2l0Y2ggdG8gcHJveG9v
bCwgSSBtdXN0IGVuc3VyZSB0aGF0IGl0IGhhcyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFu
ZCBwZXJmb3JtYW5jZSBhcyBvcmFjbGUuDQoNClRoYW5zayBmb3IgeW91ciByZXBseQ0KRGlh
cm11aWQNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHByb3hv
b2wtZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KW21haWx0bzpwcm94
b29sLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdT24gQmVoYWxmIE9m
IEJpbGwNCkhvcnNtYW4NClNlbnQ6IDE1IEp1bHkgMjAwNSAxNToxMw0KVG86IHByb3hvb2wt
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogUmU6IFtQcm94b29s
LWRldmVsb3Blcl0gVGVtcG9yYXJ5IGNyZWF0aW9uIG9mIGNvbm5lY3Rpb25zIHdoZW4NCm1h
eGltdW0gY29ubmVjdGlvbiBoYXMgYmVlbiByZWFjaGVkDQoNCg0KSGkgRGlhcm11aWQsDQoN
Ck9uIDcvMTUvMDUsIERpYXJtdWlkIE1jRG9uYWxkIDxEaWFybXVpZC5NY0RvbmFsZEB0cmF2
ZW50ZWMuY29tPiB3cm90ZToNCg0KPiBJcyBpdCBwb3NzaWJsZSB0byBzZXQgcHJveG9vbCB0
byBjcmVhdGUgbW9yZSBjb25uZWN0aW9ucyBhZnRlciB0aGUgbWF4aW11bQ0KPiBjb25uZWN0
aW9ucyBoYXMgYmVlbiBjcmVhdGVkLCBpbnN0ZWFkIG9mIHdhaXRpbmcgZm9yIGEgY29ubmVj
dGlvbiB0byBiZWNvbWUNCj4gYXZhaWxhYmxlLiANCg0KV2VsbC4uLiB5b3Ugc2V0IHRoZSBt
YXhpbXVtLWNvbm5lY3Rpb24tY291bnQgdG8gYmUgdGhlIG1heGltdW0gbnVtYmVyDQpvZiwg
ZXIsIGNvbm5lY3Rpb25zLiBXaHkgd291bGQgeW91IHdhbnQgdG8gY3JlYXRlIGZ1cnRoZXIg
Y29ubmVjdGlvbnMNCmFmdGVyIHRoYXQ/IENhbiB5b3UgZXhwbGFpbiB5b3VyIHByb2JsZW0g
YSBsaXR0bGUgbW9yZSBwbGVhc2U/DQoNCi0NCkJpbGwNCg0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTRi5OZXQgZW1haWwg
aXMgc3BvbnNvcmVkIGJ5OiBEaXNjb3ZlciBFYXN5IExpbnV4IE1pZ3JhdGlvbiBTdHJhdGVn
aWVzDQpmcm9tIElCTS4gRmluZCBzaW1wbGUgdG8gZm9sbG93IFJvYWRtYXBzLCBzdHJhaWdo
dGZvcndhcmQgYXJ0aWNsZXMsDQppbmZvcm1hdGl2ZSBXZWJjYXN0cyBhbmQgbW9yZSEgR2V0
IGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8gZ2V0IHVwIHRvDQpzcGVlZCwgZmFzdC4gaHR0cDov
L2Fkcy5vc2RuLmNvbS8/YWRfaWR0NzcmYWxsb2NfaWQWNDkyJm9wPWljaw0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClByb3hvb2wtZGV2ZWxv
cGVyIG1haWxpbmcgbGlzdA0KUHJveG9vbC1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9wcm94
b29sLWRldmVsb3Blcg0KDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0
ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQg
YXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGluZGl2aWR1YWwgbmFtZWQvIGZvciB0aGUg
dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl
c3NlZC5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlLCB5b3Ugc2hvdWxk
IG5vdCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSBvciBjb3B5IHRoaXMgZS1tYWlsLlBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIGUtbWFpbCBieSBtaXN0YWtlIGFuZCBkZWxldGUgdGhpcyBlLW1haWwgZnJvbSB5b3Vy
IHN5c3RlbS5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl
IG5vdGlmaWVkIHRoYXQgcmV2aWV3aW5nLCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmli
dXRpbmcgb3IgdGFraW5nIGFueSBhY3Rpb24gaW4gcmVsaWFuY2Ugb24gdGhlIGNvbnRlbnRz
IG9mIHRoaXMgZS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuUGxlYXNlIG5vdGUgdGhh
dCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZS1tYWlsIGFyZSBz
b2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJl
c2VudCB0aG9zZSBvZiBUcmF2ZW50ZWMgTGltaXRlZC4gVGhpcyBlLW1haWwgaGFzIGJlZW4g
c3dlcHQgZm9yIGNvbXB1dGVyIHZpcnVzZXMgaG93ZXZlciBUcmF2ZW50ZWMgTGltaXRlZCBh
Y2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVz
IHRyYW5zbWl0dGVkIGJ5IHRoaXMgZS1tYWlsLg==

Re: [Proxool-developer] Temporary creation of connections when maximum connection has been reached

[Bill H. <arc...@gm...>]

Hi Diarmuid,

On 7/15/05, Diarmuid McDonald <Dia...@tr...> wrote:

> Is it possible to set proxool to create more connections after the maximu=
m
> connections has been created, instead of waiting for a connection to beco=
me
> available.=20

Well... you set the maximum-connection-count to be the maximum number
of, er, connections. Why would you want to create further connections
after that? Can you explain your problem a little more please?

-
Bill

[Proxool-developer] Temporary creation of connections when maximum connection has been reached

[Diarmuid M. <Dia...@Tr...>]

SGkgZ3V5cywNCg0KSXMgaXQgcG9zc2libGUgdG8gc2V0IHByb3hvb2wgdG8gY3JlYXRlIG1v
cmUgY29ubmVjdGlvbnMgYWZ0ZXIgdGhlIG1heGltdW0gY29ubmVjdGlvbnMgaGFzIGJlZW4g
Y3JlYXRlZCwgaW5zdGVhZCBvZiB3YWl0aW5nIGZvciBhIGNvbm5lY3Rpb24gdG8gYmVjb21l
IGF2YWlsYWJsZS4NClRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0
aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgYXJlIGlu
dGVuZGVkIHNvbGVseSBmb3IgdGhlIGluZGl2aWR1YWwgbmFtZWQvIGZvciB0aGUgdXNlIG9m
IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC5J
ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlLCB5b3Ugc2hvdWxkIG5vdCBk
aXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSBvciBjb3B5IHRoaXMgZS1tYWlsLlBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUt
bWFpbCBieSBtaXN0YWtlIGFuZCBkZWxldGUgdGhpcyBlLW1haWwgZnJvbSB5b3VyIHN5c3Rl
bS5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlm
aWVkIHRoYXQgcmV2aWV3aW5nLCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcg
b3IgdGFraW5nIGFueSBhY3Rpb24gaW4gcmVsaWFuY2Ugb24gdGhlIGNvbnRlbnRzIG9mIHRo
aXMgZS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuUGxlYXNlIG5vdGUgdGhhdCBhbnkg
dmlld3Mgb3Igb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZS1tYWlsIGFyZSBzb2xlbHkg
dGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0
aG9zZSBvZiBUcmF2ZW50ZWMgTGltaXRlZC4gVGhpcyBlLW1haWwgaGFzIGJlZW4gc3dlcHQg
Zm9yIGNvbXB1dGVyIHZpcnVzZXMgaG93ZXZlciBUcmF2ZW50ZWMgTGltaXRlZCBhY2NlcHRz
IG5vIGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5z
bWl0dGVkIGJ5IHRoaXMgZS1tYWlsLg==

[Proxool-developer] 0.9.0 Schedule

[Bill H. <bi...@lo...>]

Hi all,

I think the time has come to ship 0.9.0. Can people get back to me if 
they know of anything that /isn't/ ready for a release (or if they would 
prefer a beta release). I've just been sent a patch (off list) for a bug 
we fixed on 16-Dec-2003 (just post 0.8.3) and it has motivated me to get 
0.9.0 out of the door. It's almost ready.

Chr, if you're not happy with the DataSource stuff at this stage then I 
suggest we postpone it to 0.9.1.

I suggest the code name "We're not dead yet" :)

-
Bill

Re: [Proxool-developer] Next Release...?

[Bill H. <bi...@lo...>]

Hi Kirk,

Kirk Daries wrote:

> Been a very happy Proxool user for about a year now.

Oh good. :)

> Just wanted to know if a new release is planned any time soon?

Any time soon, yes. The latest CVS code is ready for testing. We should
really release a beta or something so that people can test it. (Of
course, you can already do that if you check it out from cvs).

There is some work to do on documentation also.

I'm alarmed that it's been nearly 14 months since a release. Pressure of
work for allthe developers I'm afraid. There are a lot of good changes
and improvements in 0.9 that should be made available to a waiting world :)

-
Bill

[Proxool-developer] Next Release...?

[Kirk D. <Kd...@de...>]

Hi Guys,

Been a very happy Proxool user for about a year now.
Just wanted to know if a new release is planned any time soon?

Thanx,
--KD

[Proxool-developer] connectionCount problems

[Radics P. <mi...@lb...>]

Hello,

  We've run into a small problem with proxool-0.8.3 regarding connectionCount.
In some cases it's possible that a connection gets removed twice, resulting in
connectionCount in Prototyper decrease twice, thus going below zero.  This in
turn causes Prototyper to build more connections than it really needs,
resulting in more "Available" connections than the specified
maximum-connection-count.

We run into this when an Active transaction was running for too long, and 
HouseKeeper killed it at:

HouseKeeper.sweep() line: 139

then later on when we closed the connection in a finally{} block, it closed
it again:

ProxyConnection(AbstractProxyConnection).reallyClose() line: 175
ConnectionPool.removeProxyConnection(ProxyConnectionIF, String, boolean, boolean) line: 414
ProxyConnection(AbstractProxyConnection).close() line: 226
ProxyConnection.invoke(Object, Method, Object[]) line: 55
Proxy$ProxyImpl$$EnhancerByCGLIB$$5d6d109f.close() line: not available
ProxoolConnectionProvider.closeConnection(Connection) line: 73
BatchingBatcher(BatcherImpl).closeConnection(Connection) line: 305
SessionImpl.disconnect() line: 3352
SessionImpl.close() line: 576

I've attached a patch with a quick-and-dirty fix for this problem. It Works For
Us (Tm), so use at your own peril :)  Please drop me a note if a better
solution is avaliable.

(There is another connectionCount in ConnectionPool that only gets decreased,
and never increased, but that doesn't cause that big of a problem, I think.
Anyway, that patch attempts to fix that, too)

cheers,
mitch
-- 
// Radics Peter <mi...@lb...> (http://lbcons.net)
//
// "If human beings don't keep exercising their lips, 
//  their brains start working." -- Ford Prefect

[Proxool-developer] RE: Proxool code donation?

[Christian N. <chr...@em...>]

Thanks Larry.

Thats a nice christmas gift :)

We have some rudimentary DataSource support in Proxool CVS
(http://proxool.sourceforge.net/datasource.html), but have been very slow to
finalize it. I'd be happy to have a look at your code and incorporate
relevant parts in Proxool. Where in iBatis CVS is it?


CHR



> -----Original Message-----
> From: Larry Meadors [mailto:lar...@gm...]
> Sent: 24. desember 2004 04:37
> To: bil...@us...;
> be...@us...; bre...@us...;
> ch...@us...; ga...@us...;
> mus...@us...
> Subject: Proxool code donation?
>
>
> My name is Larry Meadors, and I work on the ibatis project
> (http://www.ibatis.com or http://sourceforge.net/projects/ibatisdb).
>
> A while back, I created a DataSource implementation based on proxool
> that uses a ThreadLocal user to connect to a database. What this
> allowed is user-specific pooling for applications (such as web-apps).
> Another recent addition to it was the implementation of
> getConnection(user, password) which will return a connection from the
> specified user's pool.
>
> The more I work on it, the less sense it makes to put it into iBATIS.
>
> So, do you want it to include with proxool?
>
> It is currently in the iBATIS CVS repository on sf.net, but we are
> moving to apache in the next month or two. I will glady give it to you
> if you want it, it has been used by a few of our users, and seems to
> work moderately well. I suspect if someone more intimately familiar
> with proxool could make it much more usable.
>
> I also wrote a JNDI factory for it, but am not a JNDI expert, so
> cannot say if that part is any good...but it does appear to work. ;-)
>
> Hmm, I just noticed the news on proxool.sf.net says "The next release
> of Proxool (0.9.0) will include a DataSource implementation. Our best
> guess for when this might be is December 2003 (as of 20 November
> 2003)", so this may already be done. If not, maybe this is the
> jumpstart you need to deliver it.
>
> Larry
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22.12.2004
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22.12.2004

Re: [Proxool-developer] Cast problem

[Bill H. <bi...@lo...>]

Hi Roman,

Prigozhin, Roman wrote:

>         I'm using proxool and very happy with it. There is a small 
> problem I'm having casting connection object :
>   SCStatement = (OracleCallableStatement) SCConn.prepareCall(....) Is 
> there any way to do it ? Everywhere in my code I'm using regular 
> connection object so proxool works fine, there is only one place where I 
> need driver specific functionality.

Depending on what version of the Oracle driver you are using, this 
should be possible with the latest code from CVS. (It depends on whether 
  OracleCallableStatement is an inteface or not).

But if you want to stick with 0.8.3 then you can achieve the same with 
ProxoolFacade.getDelegateStatement(Statement).

- Bill

[Proxool-developer] Cast problem

[Prigozhin, R. <Rom...@ob...>]

Hi All,
	I'm using proxool and very happy with it. There is a small problem I'm =
having casting connection object :
  SCStatement =3D (OracleCallableStatement) SCConn.prepareCall(....) Is =
there any way to do it ? Everywhere in my code I'm using regular =
connection object so proxool works fine, there is only one place where I =
need driver specific functionality.=20

Thanks,
Roman

###########################################=0A=
=0A=
This message has been scanned by F-Secure Anti-Virus for Microsoft =
Exchange.=0A=
For more information, connect to http://www.F-Secure.com/

Re: [Proxool-developer] Proxool under JRUN?

[Bill H. <bi...@lo...>]

Hi Jon,

Jon Austin wrote:

>The output was simply
>
>embedded=true
>
>I'm wondering if JRUN is adding that, as the spring/hibernate combination
>isn't behaving that way under tomcat.
>  
>

I can only assume your right. Hmm. The only solution that I can see is 
to check for that in the info object specifically. I would prefer for 
Proxool not to do that since it only takes JRUN to change that for it to 
break again.

Another option is for you to not configure Proxool with XML but instead 
pass in the info object each time. Obviously, you'd want to create your 
own wrapper for that. That way, ProxoolDriver would always receive an 
identical info object and the pool wouldn't be redefined.

It may seem like a simple fix to detect "embedded=true" and ignore it, 
but that means we are breaking a contract: someone passes a property to 
the driver and it is ignored. I've no idea why JRUN decides to send this 
property but it would be wrong for Proxool to make adjustments for it.

If you wanted to, you could write your own JRUN JDBC driver that just 
took a URL like "jrun.foo", stripped out the "embedded=true" property 
and passed it on to the DriverManager as just "foo". That means you 
could configure Proxool how you liked.

If none of these options seem appealing then get back to me, and we'll 
see what we can do.

- Bill

BTW, you would have received an answer on the proxool-user list too 
eventually. Most developers listen to both lists I think.

Re: [Proxool-developer] Proxool under JRUN?

[Bill H. <bi...@lo...>]

Hi Jon,

Jon Austin wrote:

>The difference between the two appears to be, that ProxoolDriver.connect, is
>being called with "something" in the info param when running in JRUN.
>
>If I comment out the whole
>
>	"else if (info != null && info.size() > 0) { ... }"
>
>block, and just let the else catch it, then it works in JRUN, however I
>don't really want to deploy a non-standard proxool version.
>  
>

I'd be interested to know what that info Properties object contained, 
and what component is creating it. Perhaps Spring or Hibernate assume 
that they have to pass in the username and password everytime (which 
doesn't sound unreasonable).

Can you add some debug output to show each key/value pair within that 
info object?

- Bill

[Proxool-developer] Proxool under JRUN?

[<ja...@ec...>]

I have a spring/hibernate/proxool app running under tomcat without issue.

I need to port it to JRUN for a customer requirement, and while Spring and
Hibernate are running successfully, Proxool is giving me issues.

I downloaded the source, and started playing with some debug messages to see
what was going on..

Anyway, for some reason under tomcat, the initialization goes through, sets
up the alias, and goes about waiting for something to do.

JRUN however, goes through and initializes, then when the connect method is
called, it decides to perform a redefine, and wipes out the settings.

The difference between the two appears to be, that ProxoolDriver.connect, is
being called with "something" in the info param when running in JRUN.

If I comment out the whole

	"else if (info != null && info.size() > 0) { ... }"

block, and just let the else catch it, then it works in JRUN, however I
don't really want to deploy a non-standard proxool version.

Does anyone know why JRUN might cause info to be submitted differently, and
if there's a simple fix without customizing our proxool release?

Thanks!

~ Jon




WARNING:  The information contained in this message and any attachments is
intended only for the use of the individual or entity to which it is
addressed.  This message may contain information that is privileged,
confidential and exempt from disclosure under applicable law.  It may also
contain trade secrets and other proprietary information for which you and
your employer may be held liable for disclosing.  You are hereby notified
that any unauthorized dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error,  please notify HI...@ec... by E-Mail and then
destroy this communication in a manner appropriate for privileged
information.

RE: [Proxool-developer] Connections closing

[Joe S. <joe...@e-...>]

Hi Christian,

Yes its definitely transactional locking... as far as I can tell for code/SQL that 
shouldn't have any issues either... seems MSSQL is pretty keen to decide what 
types of locks it wants when row locks are what is required (why would it 
acquire a table lock when I use a query with the tables PK e.g. ID=1??).

Not really interested in forcing MSSQL by using hints, I'm going to recommend a 
move to a different driver and db.

Regards,
Joe

> The connection have been closed after the default maximum time it is allowed
> to remain active (5 minutes - 300000 milliseconds).
> 
> If you are running queries/updates that you expect to take longer than this
> you need to set the 'maximum-active-time' property to something larger than
> 300000.
> 
> Here are some suggestions if you do not expect your query/update to take
> that long:
> 
> 1) Your query/update is taking longer than expected, for instance due to
> excessive transactional locking. This is typically something that will
> manifest itself in a multithreaded production environment, but not in a
> single threaded development environment.
> 
> 2) You are forgetting to close your connections somewhere.
> 
> 3) You have aquired a reference to the original Connection that Proxool is
> wrapping (by calling ProxoolFacade.getDelegateConnection(Connection
> connection)) and are calling 'close' on that instad of on the Proxool
> Connection.
> 
> CHR
> 
> > -----Original Message-----
> > From: pro...@li...
> > [mailto:pro...@li...]On Behalf Of Joe
> > Shevland
> > Sent: 28. oktober 2004 17:47
> > To: pro...@li...
> > Subject: [Proxool-developer] Connections closing
> >
> >
> > Hi,
> >
> > Apologies about not doing a bit more research, but I'm in a
> > fairly desperate
> > state.
> >
> > We're using the Proxool pooling library; throughout development the pools
> > worked fine but now in production we're seeing errors where the pools are
> > closing connections after they remain open too long.
> >
> > The errors occur when Proxool kills connecitons that exceed the maximum
> > active time:
> >
> >   2004-10-28 11:53:01,206  WARN #0075 was active for 306810
> > milliseconds and
> > has been removed automaticaly. The Thread responsible was named
> > 'PoolThread-2'.
> >
> > The big problem that is causing flow-on effects, is that these connections
> > are still being used by active threads e.g.
> >
> >   2004-10-28 11:53:01,206 ERROR problem occurred processing replication
> > file; aborting
> >   java.sql.SQLException: Network error: socket closed
> >
> > I'm pretty desperate for options on how to make this behave better under
> > load - I've had a pretty exhaustive look through the code and all
> > connections are .close()'d as far as I can tell in finally clauses... Is
> > there anything I can do to make the connection 'killing' less savage for
> > clients that might be using the connection?
> >
> > I'm not on the list just yet, please if there's any suggestions reply in
> > person also.
> >
> > Cheers,
> > Joe
> >
> > Joe Shevland
> > Senior Developer
> > e-Wise Solutions
> >
> > WWW : http://www.e-wise.com Email: joe...@e-...
> > Tel.: +61-(0)3-9593-2485    Fax.: +61-(0)3-9593-2645
> > Cell: +61-(0)418-547-342
> >
> > CAUTION - This message may contain privileged and confidential information
> > intended only for the use of the addressee named above. If you are not the
> > intended recipient of this message you are hereby notified that any use,
> > dissemination, distribution or reproduction of this message is prohibited.
> > If you have received this message in error please notify E-Wise Solutions
> > immediately. Any views expressed in this message are those of the
> > individual sender and may not necessarily reflect the views of E-Wise
> > Solutions.
> >
> >
> >
> > -------------------------------------------------------
> > This Newsletter Sponsored by: Macrovision
> > For reliable Linux application installations, use the industry's leading
> > setup authoring tool, InstallShield X. Learn more and evaluate
> > today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
> > _______________________________________________
> > Proxool-developer mailing list
> > Pro...@li...
> > https://lists.sourceforge.net/lists/listinfo/proxool-developer
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.778 / Virus Database: 525 - Release Date: 15.10.2004
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.778 / Virus Database: 525 - Release Date: 15.10.2004



Joe Shevland
Senior Developer
e-Wise Solutions Pty Ltd

RE: [Proxool-developer] Connections closing

[<chr...@em...>]

The connection have been closed after the default maximum time it is allowed
to remain active (5 minutes - 300000 milliseconds).

If you are running queries/updates that you expect to take longer than this
you need to set the 'maximum-active-time' property to something larger than
300000.

Here are some suggestions if you do not expect your query/update to take
that long:

1) Your query/update is taking longer than expected, for instance due to
excessive transactional locking. This is typically something that will
manifest itself in a multithreaded production environment, but not in a
single threaded development environment.

2) You are forgetting to close your connections somewhere.

3) You have aquired a reference to the original Connection that Proxool is
wrapping (by calling ProxoolFacade.getDelegateConnection(Connection
connection)) and are calling 'close' on that instad of on the Proxool
Connection.



CHR


> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Joe
> Shevland
> Sent: 28. oktober 2004 17:47
> To: pro...@li...
> Subject: [Proxool-developer] Connections closing
>
>
> Hi,
>
> Apologies about not doing a bit more research, but I'm in a
> fairly desperate
> state.
>
> We're using the Proxool pooling library; throughout development the pools
> worked fine but now in production we're seeing errors where the pools are
> closing connections after they remain open too long.
>
> The errors occur when Proxool kills connecitons that exceed the maximum
> active time:
>
>   2004-10-28 11:53:01,206  WARN #0075 was active for 306810
> milliseconds and
> has been removed automaticaly. The Thread responsible was named
> 'PoolThread-2'.
>
> The big problem that is causing flow-on effects, is that these connections
> are still being used by active threads e.g.
>
>   2004-10-28 11:53:01,206 ERROR problem occurred processing replication
> file; aborting
>   java.sql.SQLException: Network error: socket closed
>
> I'm pretty desperate for options on how to make this behave better under
> load - I've had a pretty exhaustive look through the code and all
> connections are .close()'d as far as I can tell in finally clauses... Is
> there anything I can do to make the connection 'killing' less savage for
> clients that might be using the connection?
>
> I'm not on the list just yet, please if there's any suggestions reply in
> person also.
>
> Cheers,
> Joe
>
> Joe Shevland
> Senior Developer
> e-Wise Solutions
>
> WWW : http://www.e-wise.com Email: joe...@e-...
> Tel.: +61-(0)3-9593-2485    Fax.: +61-(0)3-9593-2645
> Cell: +61-(0)418-547-342
>
> CAUTION - This message may contain privileged and confidential information
> intended only for the use of the addressee named above. If you are not the
> intended recipient of this message you are hereby notified that any use,
> dissemination, distribution or reproduction of this message is prohibited.
> If you have received this message in error please notify E-Wise Solutions
> immediately. Any views expressed in this message are those of the
> individual sender and may not necessarily reflect the views of E-Wise
> Solutions.
>
>
>
> -------------------------------------------------------
> This Newsletter Sponsored by: Macrovision
> For reliable Linux application installations, use the industry's leading
> setup authoring tool, InstallShield X. Learn more and evaluate
> today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.778 / Virus Database: 525 - Release Date: 15.10.2004
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15.10.2004

[Proxool-developer] Connections closing

[Joe S. <joe...@e-...>]

Hi,

Apologies about not doing a bit more research, but I'm in a fairly =
desperate
state.

We're using the Proxool pooling library; throughout development the =
pools
worked fine but now in production we're seeing errors where the pools =
are
closing connections after they remain open too long.

The errors occur when Proxool kills connecitons that exceed the maximum
active time:

  2004-10-28 11:53:01,206  WARN #0075 was active for 306810 milliseconds =
and
has been removed automaticaly. The Thread responsible was named
'PoolThread-2'.

The big problem that is causing flow-on effects, is that these =
connections
are still being used by active threads e.g.

  2004-10-28 11:53:01,206 ERROR problem occurred processing replication
file; aborting
  java.sql.SQLException: Network error: socket closed

I'm pretty desperate for options on how to make this behave better under
load - I've had a pretty exhaustive look through the code and all
connections are .close()'d as far as I can tell in finally clauses... Is
there anything I can do to make the connection 'killing' less savage for
clients that might be using the connection?

I'm not on the list just yet, please if there's any suggestions reply in
person also.

Cheers,
Joe

Joe Shevland
Senior Developer
e-Wise Solutions

WWW : http://www.e-wise.com Email: joe...@e-...
Tel.: +61-(0)3-9593-2485    Fax.: +61-(0)3-9593-2645
Cell: +61-(0)418-547-342

CAUTION - This message may contain privileged and confidential =
information
intended only for the use of the addressee named above. If you are not =
the
intended recipient of this message you are hereby notified that any use,
dissemination, distribution or reproduction of this message is =
prohibited.
If you have received this message in error please notify E-Wise =
Solutions
immediately. Any views expressed in this message are those of the
individual sender and may not necessarily reflect the views of E-Wise
Solutions.

RE: [Proxool-developer] Re: Proxool behavior when max connection reached

[<chr...@em...>]

Nothing has been done so far, and your help is greatly apreciated :)

You might want to draw some inspiration from the GenericObjectPool code from
Jakarta, it has a configrable whenExhaustedAction:
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/
GenericObjectPool.html

CHR

> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Craig
> Servin
> Sent: 8. oktober 2004 07:58
> To: pro...@li...
> Subject: [Proxool-developer] Re: Proxool behavior when max connection
> reached
>
>
> I am following up on an old thread about causing calling threads
> to wait for a
> connection rather than getting an Exception.  It looks like this
> has not been
> done in CVS yet.
>
> Has anyone looked at doing this?  If not, since I need the
> behavior, I will
> try to work on it.  But, I do not want to repeat work so I
> thought I would
> ask before I tried to add that feature.
>
> Craig
>
>
> On Saturday 15 May 2004 03:40 pm, Bertrand Renuart wrote:
> > Thanks for your information Craig.
> >
> > Work has already started on this feature together with some other
> > refactoring.
> > I don't know yet when it will be released but part of it may be
> available
> > soon in CVS. Keep listening on proxool-dev mailing list - I'll post a
> > message when it will start becoming available.
> >
> > -bertrand
> >
> >
> > -----Original Message-----
> > From: pro...@li...
> > [mailto:pro...@li...] On
> Behalf Of Craig
> > Servin
> > Sent: samedi 15 mai 2004 21:45
> > To: pro...@li...
> > Subject: [Proxool-developer] Re: Proxool behavior when max connection
> > reached
> >
> >
> > Has any work been done on this.  I need a similar behavior and
> might try to
> > implement it, but I do not want to duplicate effort.
> >
> > It seems that you would not need to more settings you would just need an
> > allowed to wait count which if it was not 0 would make your normal limit
> > your
> > soft limit and then add to it for the hard limit.
> >
> > It looks like there are only 2 spots in the code that would need to be
> > changed, but since the current code tries very hard not to
> synchronize I am
> > not sure of the best way to do this.  It would seem that if you
> would allow
> > for threads to wait you would want to synchronize at that point and then
> > notify the threads as a connection is returned.  You could  simply check
> > for
> >
> > that feature being tunred on and only synchronize then, but you
> would have
> > to
> > make sure that if you hot change the settings to disable the
> waiting that
> > you
> > notify the waiting threads.
> >
> >
> >
> > Craig
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer