proxool-developer — Developer's discussion list

Re: [Proxool-developer] Getting ready for 1.0

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

On Mon, 2003-02-24 at 16:31, Martin Crawford wrote:

> The apache libraries best to consider are:
> http://ws.apache.org/xmlrpc/
> http://ws.apache.org/soap/index.html
<snip>
> Actually what I meant was implementing an XML-RPC and/or SOAP layer to 
> support the ProxoolFacade.

Sounds good.

> Now this would be cool. Acutally I again was referring that the XML-RPC 
> and/or SOAP layers would be useful to manually redirect/switch over, but 
> automatic is much cooler!

Yeah, that's what we thought. I think it might take a while to get it to
behave properly and mature a little though. So planned for 1.1 (but
those no reason why 1.1 shouldn't happen within the next few months).

> I guess the overall idea is to find 
> ways to make Proxool easily pluginable to any framework to make it more 
> marketable. 

Yep.

> Hibernate has built in a "non-production" ready pool manager. But for 
> production it provides either pool manager hooks to use either c3po, 
> DBCP or a DataSource (BTW this would be another good thing to support, 
> but this is an old request I think). 

Yeah, we'll take a deep breath and support DataSource sometime. 1.1+ I
think.

> We would only need to implement 
> this interface http://hibernate.bluemars.net/hib_docs/api/ and come up 
> with a similar property passing solution as 
> http://hibernate.bluemars.net/hib_docs/reference/html/session-configuration.html#session-configuration-s4. 

Yep, looks like that would be fairly simple to implement. Presumably, we
could then contribute our ProxoolConnectionProvider to the Hibernate
project? Do you have some contacts from Hibernate so that we can discuss
how best to do this? I don't suppose they'll want to add Proxool support
until we are at 1.0. And that won't be for another month (I'm guessing).

> >My opinion is that we shouldn't try and squeeze much more into 1.0 and
> >we should plant our feet firmly in the ground and say "it's ready!".
> >  
> >
> I fully agree, but you ask for the shopping list;)

Yeah, I asked for it! I think I'll add a RoadMap to the web site for all
this stuff. But I suppose I should wait for your doc freeze to be
complete first. Actually, I am just making a link fix now. Perhaps I
should just tell you what it is:

listen.html has links to:
api/org/logicalcobwebs/proxool/StatisticsListenerIF.html, and
api/org/logicalcobwebs/proxool/StatisticsIF.html

they should have the admin package in the path:
api/org/logicalcobwebs/proxool/admin/StatisticsListenerIF.html, and
api/org/logicalcobwebs/proxool/admin/StatisticsIF.html

> Although it would be good to have support for Hibernate 2.0 before it is 
> release (there are no dates but I imagine soon). I feel it will probably 
> become a high profile project with this release and it would be great 
> "marketing" to be associated with it....

Yeah, it would be great to be associated with Hibernate. Do you want to
talk to them, or shall I?

-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Getting ready for 1.0

[Martin C. <mus...@us...>]

>
>
>Sounds interesting. I don't know much about XML-RPC/SOAP though.
>
They are two standards for remote method invocation based on XML. For 
example (http://www.xmlrpc.org/) for details about the one spec (this 
one is very lightweight IMHO than SOAP, but the industry likes SOAP 
because it's more featureful).

The apache libraries best to consider are:
http://ws.apache.org/xmlrpc/
http://ws.apache.org/soap/index.html

>  
>
>>I guess just implementing the ProxoolFacade class? 
>>    
>>
>
>Well, ProxoolFacade isn't an interface :) It could use ProxoolFacade if
>it liked.
>  
>
Actually what I meant was implementing an XML-RPC and/or SOAP layer to 
support the ProxoolFacade.

>  
>
>>Might be a useful option to handle to support the switching of
>>database URLs in failover situations on non-servlet solutions (i.e.
>>bundle with the driver, and activate via XML or Properties). 
>>    
>>
>We already allow switching of databases: either programmatically, or
>with the upcoming JMX component or with the next version of
>AdminServlet. If you mean _automatic_ switching then this is something
>that Del Simmons has been talking about for a while. It would be really
>cool and will probably be in 1.1.
>  
>
Now this would be cool. Acutally I again was referring that the XML-RPC 
and/or SOAP layers would be useful to manually redirect/switch over, but 
automatic is much cooler!

>  
>
>>Other thoughts is looking at other "delfacto" frameworks like Struts,
>>Maverin, etc, and see what simple hooks we can provide to make
>>integration seemless. 
>>    
>>
>I know Struts quite well and I can't really think of anything we could
>do that isn't already provided by the AdminServlet. We could produce a
>Struts version of the AdminServlet (called, say, AdminAction) but it
>would just end up duplicating AdminServlet. (Background: AdminServlet
>does everything in a very simple way: HTML is coded in the Java class,
>request parameters are extracted manually. All the things that would
>make a servlet app a nightmare, and how we used to do it a long time
>ago. However, because the scope of the servlet isn't very much, the
>advantages we get in very simple configuration - no JSPs - outweigh
>this, I believe.)
>
I agree lightweight is good aproach, I just threw Struts on the floor 
again because it's becoming a delfacto and the "tight integration" would 
be another sell feature.

>
>We do already provide an AvalonConfigurator. What's Maverin?
>  
>
I swear I ran across Maverin as another up-and-coming framework... but 
perhaps it was just a brain fart! I guess the overall idea is to find 
ways to make Proxool easily pluginable to any framework to make it more 
marketable. 

>  
>
>>Also I've been using Hibernate (http://hibernate.sf.net) lately, and
>>have contributed a little documentation and feedback on version 2.0
>>which is still in beta. Would be nice to provide a Proxool integration
>>as one of the pool managers it would use. I'll look into maybe working
>>on this.
>>    
>>
>
>I'd be interested to learn how we can integrate with Hibernate. Doesn't
>it just rely on any JDBC driver, or is it more complicated than that?
>  
>
Hibernate has built in a "non-production" ready pool manager. But for 
production it provides either pool manager hooks to use either c3po, 
DBCP or a DataSource (BTW this would be another good thing to support, 
but this is an old request I think). We would only need to implement 
this interface http://hibernate.bluemars.net/hib_docs/api/ and come up 
with a similar property passing solution as 
http://hibernate.bluemars.net/hib_docs/reference/html/session-configuration.html#session-configuration-s4. 

>3) Very good documentation. We're nearly there with this. Even closer
>with DocBook. 
>  
>
:)

>My opinion is that we shouldn't try and squeeze much more into 1.0 and
>we should plant our feet firmly in the ground and say "it's ready!".
>  
>
I fully agree, but you ask for the shopping list;)

Although it would be good to have support for Hibernate 2.0 before it is 
release (there are no dates but I imagine soon). I feel it will probably 
become a high profile project with this release and it would be great 
"marketing" to be associated with it....

Ok off to the races on Docbook...
Martin

Re: [Proxool-developer] Getting ready for 1.0

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

> Would an XML-RPC or SOAP 
> interface be useful for remote management 
> of pools? I guess just implementing the 
> ProxoolFacade class? 

+1 

CHR

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [Proxool-developer] Getting ready for 1.0

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

On Mon, 2003-02-24 at 12:19, mar...@sy... wrote:

> Would an XML-RPC or SOAP interface be useful for remote management of
> pools? 

Sounds interesting. I don't know much about XML-RPC/SOAP though.

> I guess just implementing the ProxoolFacade class? 

Well, ProxoolFacade isn't an interface :) It could use ProxoolFacade if
it liked.

> Might be a useful option to handle to support the switching of
> database URLs in failover situations on non-servlet solutions (i.e.
> bundle with the driver, and activate via XML or Properties). 

We already allow switching of databases: either programmatically, or
with the upcoming JMX component or with the next version of
AdminServlet. If you mean _automatic_ switching then this is something
that Del Simmons has been talking about for a while. It would be really
cool and will probably be in 1.1.

> Other thoughts is looking at other "delfacto" frameworks like Struts,
> Maverin, etc, and see what simple hooks we can provide to make
> integration seemless. 

I know Struts quite well and I can't really think of anything we could
do that isn't already provided by the AdminServlet. We could produce a
Struts version of the AdminServlet (called, say, AdminAction) but it
would just end up duplicating AdminServlet. (Background: AdminServlet
does everything in a very simple way: HTML is coded in the Java class,
request parameters are extracted manually. All the things that would
make a servlet app a nightmare, and how we used to do it a long time
ago. However, because the scope of the servlet isn't very much, the
advantages we get in very simple configuration - no JSPs - outweigh
this, I believe.)

We do already provide an AvalonConfigurator. What's Maverin?

> Also I've been using Hibernate (http://hibernate.sf.net) lately, and
> have contributed a little documentation and feedback on version 2.0
> which is still in beta. Would be nice to provide a Proxool integration
> as one of the pool managers it would use. I'll look into maybe working
> on this.

I'd be interested to learn how we can integrate with Hibernate. Doesn't
it just rely on any JDBC driver, or is it more complicated than that?

---

I think my question could actually be better rephrased as: "are there
any changes/features that should be in 1.0 rather than later?" Or to
attempt that again, "what are the objectives of a 1.0 release?" I would
suggest the miniumum is:

1) Robustness: no critical bugs (we have no bugs at all just now)

2) Fixed API (we have already fixed the API so that code that works with
0.7 will (probably) work with 1.0.

3) Very good documentation. We're nearly there with this. Even closer
with DocBook. 

4) Easy configuration. I think we are there with 0.7.

So, the list beyond that is just additional features that make us
competitive with the other pools. Like JMX (coming in 0.8), SOAP?, and
so on.

My opinion is that we shouldn't try and squeeze much more into 1.0 and
we should plant our feet firmly in the ground and say "it's ready!".

> Hey, dreamer boy get back to your documentation!

Keep up with the good work, Martin!

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Getting ready for 1.0

[<mar...@sy...>]

Haven't had a chance to try the AdminServlet so maybe this is already there and is more duplication. Would an XML-RPC or SOAP interface be useful for remote management of pools? I guess just implementing the ProxoolFacade class? 

Might be a useful option to handle to support the switching of database URLs in failover situations on non-servlet solutions (i.e. bundle with the driver, and activate via XML or Properties). 

Other thoughts is looking at other "delfacto" frameworks like Struts, Maverin, etc, and see what simple hooks we can provide to make integration seemless. Also I've been using Hibernate (http://hibernate.sf.net) lately, and have contributed a little documentation and feedback on version 2.0 which is still in beta. Would be nice to provide a Proxool integration as one of the pool managers it would use. I'll look into maybe working on this.

Now I'm just dreaming... (A voice from the front of the class) Hey, dreamer boy get back to your documentation!

Martin

PS: On the URL question: Close all the connections immediately on a URL change is my vote. I think the fail-over features will be a really unique selling feature for Proxool. Worth some effort on the niceties.

> 
> From: Bill Horsman <bi...@lo...>
> Date: 2003/02/24 Mon AM 06:17:50 EST
> To: Proxool Developer List <pro...@li...>
> Subject: [Proxool-developer] Getting ready for 1.0
> 
> Hi all,
> 
> What do we need to do to reach 1.0? I think we're _almost_ there. Martin
> and Christian are working on DocBook and Christian is completing a JMX
> implementation for 0.8.
> 
> I'd like to make the new AdminServlet a bit better: make it possible to
> update the definition for each pool. Perhaps provide some more
> descriptive information about what all the definitions mean.
> 
> Does anyone want to lobby for any other simple features that we could
> include. I don't want to do anything fundamental that will delay 1.0 -
> things like failover database switching can wait until 1.1.
> 
> Cheers,
> -- 
>   Bill Horsman
>   Proxool
>   http://proxool.sourceforge.net
>   ICQ: 119577180
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
> 

[Proxool-developer] Getting ready for 1.0

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

Hi all,

What do we need to do to reach 1.0? I think we're _almost_ there. Martin
and Christian are working on DocBook and Christian is completing a JMX
implementation for 0.8.

I'd like to make the new AdminServlet a bit better: make it possible to
update the definition for each pool. Perhaps provide some more
descriptive information about what all the definitions mean.

Does anyone want to lobby for any other simple features that we could
include. I don't want to do anything fundamental that will delay 1.0 -
things like failover database switching can wait until 1.1.

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Documentation for 0.8

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

Martin,

On Sat, 2003-02-22 at 00:36, mar...@sy... wrote:

> Could we freeze the documentation? 

Yep, good idea. Consider it frozen.

> I will aim to get everything ported over to Docbook by the end of the
> month and into CVS. Then anyone can make updates to the Docbook, while
> I work on some translation stylesheets for the website (and perhaps a
> HOWTO: to build and generate with the DocBook Ant script).

Sounds wise. 

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] Documentation for 0.8

[<mar...@sy...>]

All.

Could we freeze the documentation? I will aim to get everything ported over to Docbook by the end of the month and into CVS. Then anyone can make updates to the Docbook, while I work on some translation stylesheets for the website (and perhaps a HOWTO: to build and generate with the DocBook Ant script).

Cheers.
Martin

 
> From: Bill Horsman <bi...@lo...>
> Date: 2003/02/21 Fri PM 12:25:32 EST
> To: Proxool Developer List <pro...@li...>
> Subject: [Proxool-developer] Release 0.7
> 
> Hi all,
> 
> Just released 0.7. And shifted the "dev" web site into production. I
> hope you all enjoy it.
> 
> Regards,
> -- 
>   Bill Horsman
>   Proxool
>   http://proxool.sourceforge.net
>   ICQ: 119577180
> 
> 
> 

[Proxool-developer] Release 0.7

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

Hi all,

Just released 0.7. And shifted the "dev" web site into production. I
hope you all enjoy it.

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] Changing Databases (URLs) while Proxool is running

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

Hi all,

At the moment, if you change the URL that Proxool uses to connect to the
database (say if you want to switch databases) then that new URL is only
used for new connections. The existing ones continue to use the old
database. You have to call ProxoolFacade.killAllConnections to get it to
work fast.

The idea behind that was that killing all connections is a bad thing to
do because if you are busy you are likely to refuse some people while
you build new ones.

But I'm changing my mind. I think the user would rightly expect the new
database to start serving all the connections pretty quickly, as default
behaviour.

Note: if you are changing databases because the old one is down and you
have correctly configured fatal-sql-exception then the old connections
will get killed off anyway (see my previous post "When connections
fail").

So, the question is: should changing the URL trigger killAllConnections?

Another note: killAllConnections' default behaviour is to be "merciful"
and only destroy the connections once they become available (so no
active connections are interrupted).

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] When connections fail

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

Hi all,

This is a summary of an IM discussion between myself and Del Simmons
(who has subsequently joined this list - welcome Del).

Del has a setup where if a database fails than the IP is transparently
switched to a new database. When this happens, all the existing 
connections will be "bad".

If you have configured house-keeper-test-sql then they will be caught by
the next sweep of the house keeper, but that might not be for another 30
seconds or so and in the meantime you might refuse a lot of connections.
And if you are busy then you will have more active connections (and
active connections aren't tested, obviously).

If you configure fatal-sql-exception (you'll have to test on your
particular database what exception messages you are looking for) then
each connection will refuse exactly one client before destroying itself.

It would be nice to continue the client's execution with a new
connection - transparently. Only that is a bit tricky. Consider this:

  Connection connection = DriverManager.getConnection("proxool.example:org.hsqldb.jdbcDriver:jdbc:hsqldb:test");

  // Some preparation
  connection.setAutoCommit(false);
  Statement s = connection.prepareStatement("SELECT * FROM MY_TABLE;");  
  
  // Execute it (this is the bit that causes the SQLException because
  // the database is down.
  s.execute();

The problem is that Proxool won't know there's a problem until it tries
to execute the statement. If, at that point, it decides to try again
with a brand new connection then it will have to recreate the
preparation phase, and that might be a lot more complicated than this
example.

At the app level you might consider putting the whole of this code into
a short loop (if you're that interested in avoiding a refusal). But
making it transparent within Proxool is a little more involved.

A compromise might be that if we ever get a fatal sql exception then we
immediately wake up the house keeper thread so that we minimise the
refusals. (Note - I have just implemented this in version 0.6.4)

Another might be that we test each connection when we serve it to see if
it is ok. This might be some SQL (as defined in house-keeper-test-sql),.
but that will add an unacceptable performance overhead. Are there any
quick operations we can call on a Connection to check to see if it is
really connected to an operating database?

(Note, this message is being resent - it never arrived last time for
some reason. Apologies if it becomes a duplicate.)

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] 0.6.4

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

Hi all,

I've just released version 0.6.4 (release candidate 1 for 0.7). It's
"hidden" and only available from the dev web site:

  http://proxool.sourceforge.net/dev/

Follow the links on the download page if you want to grab a copy and see
if there are any problems with it.

If all goes well I will be releasing 0.7 in the next day or so. Need to
be reminded of all that has changed since 0.6?

- We have dropped the dependency on commons-logging.jar by copying the
code into our own project (retaining credit to the Jakarta team,
naturally). 

- New Admin package provides statistical and snapshot information so you
can measure how well Proxool, and your database, is doing. 

- New AdminServlet provides statistical information for your web
application. 

- The JDK 1.2 patch code has been brought up to date and now passes all
the unit tests. 

- The listener code has been redone. Proxool now allows multiple
listeners per pool. setFooListener has now been deprecated in favour of
addFooListener. And it's now thread safe (just in case you add or remove
a listener while the pool is running). 

- The new ServletConfigurator will help you to configure and shutdown
your pools simply by adding a few lines to your servlet configuration
(web.xml) file and perhaps writing an XML file. No changes to your Java
code. 

- By using ShutdownHooks (with JDK1.3 or later) we get a cleaner, more
reliable shutdown of the pools when the JVM stops. 

- Fixed bug when you asked DatabaseMetaData for the connection. It now
gives you back the Proxool connection, not the underlying delegate
connection. 

- Fixed bug where if you registered, removed and then re-registered a
pool then the new pool would not notice the Properties passed to it. 

- (late edition not in changelog yet) if a connection encounters a fatal
sql exception it wakes up the house keeper thread so other connections
are tested as soon as possible.

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] Status of 0.7

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

Hi all,

We're quite close to version 0.7 now. You can see what's already
complete at:

  http://proxool.sourceforge.net/dev/changelog.html

---

Still to do:

1. Chr to complete unit tests for listener stuff.

2. Add a bit more to the doc (see http://proxool.sourceforge.net/dev)
for the draft, updated version that will ship with 0.7. 

---

Stuff that might sneak in (or will otherwise be in 0.8):

1. J2SE compliance test results.

---

Stuff scheduled for 0.8

1. Convert documentation to DocBook format.

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Scrollable Cursor Support

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

Andrew,

On Fri, 2003-02-07 at 11:56, Andrey Budarevsky wrote:

> This could be a feature to support scrollable cursors for drivers that don't
> have one. I am not sure it is worth, it depends on final target of your
> project. It's just an idea.

Ah, I see what you mean. I suppose that would be possible. Like you say,
I'm not sure if that is really the objective of Proxool and it does
sound quite involved. Still, thanks for the suggestion. 

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Scrollable Cursor Support

[Andrey B. <ne...@my...>]

> On Fri, 2003-02-07 at 11:33, Andrey Budarevsky wrote:
>
> > Currently I have a question about transparent support of scrollable
cursors.
> > For example ODBC bridge doesn't support result set navigation and result
set
> > update. What do you think of that?
>
> As far as I know, scrollable cursor support will depend on the delegate
> driver. So if that driver supports it, so will Proxool. When you ask a
> Statemet for a ResultSet you get the actual ResultSet from the delegate
> driver (no proxying). I say "as far as I know" because this isn't
> tested. (Although I believe Bas and Alastair include this in their J2SE
> compliance test - coming soon).

This could be a feature to support scrollable cursors for drivers that don't
have one. I am not sure it is worth, it depends on final target of your
project. It's just an idea.

Andrew.

Re: [Proxool-developer] JMX and Frameworks (was no subject)

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

Hi Andrew,

On Fri, 2003-02-07 at 11:33, Andrey Budarevsky wrote:

> Currently I have a question about transparent support of scrollable cursors.
> For example ODBC bridge doesn't support result set navigation and result set
> update. What do you think of that?

As far as I know, scrollable cursor support will depend on the delegate
driver. So if that driver supports it, so will Proxool. When you ask a
Statemet for a ResultSet you get the actual ResultSet from the delegate
driver (no proxying). I say "as far as I know" because this isn't
tested. (Although I believe Bas and Alastair include this in their J2SE
compliance test - coming soon).

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] JMX and Frameworks (was no subject)

[Andrey B. <ne...@my...>]

Hello All!

Sorry for missed subject. I had some troubles with my mail client and had to
use web mail which is inconvenient.

>
> > If mentioned above web application has failed the proxool should
> > receive the same shutdown message (facade shutdownHook is called) or
> > another message like reinitialize the pools or what is most fit the
> > requirements.
>
> Andrew, you're going to have to resort to specifics here. This is all a
> bit vague. I think the API already supports shutdown; the exact
> mechanism of that shutdown must depend on the environment that Proxool
> is running in.
>
> In what way do you think current Proxool API limits you?

I was speaking about pricinpals, not the missing features. Probably it was a
bit more theoretical than needed ;) I do not have any limits on using
Proxool, just terms are very important when you speak about architecture.
Very often people understand the same terms diferenly. So let's skip that.
Currently I have a question about transparent support of scrollable cursors.
For example ODBC bridge doesn't support result set navigation and result set
update. What do you think of that?

Sorry for misleading.

Andrew.

Re: [Proxool-developer] JMX and Frameworks (was no subject)

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

Hi Andrew,

On Wed, 2003-02-05 at 23:02, Andrew Budarevsky wrote:

> We could touch this. I don't see any problems. The main competitor of
> Proxool - PoolMan was jmx compatible.

Yep, it's in the plan. Christian intends to write this before 1.0. We
like JMX.

> Let's say we provide few reactions of proxool which are supposed to be
> mapped by framework proxy on framework's events. E.g.: we use a
> proxool inside of web application and we have to close connections on
> destroying of this application. We cannot wait for JVM shutdown. In
> this case web application is the framework in which the proxool is
> nested. Not the servlet engine! 

Ok. Let me be clearer. At the moment we have an adapter (if you want to
call it that) ServletConfigurator that will do this shutdown for you. It
works in Servlet Containers - obviously. I don't see any problem in
writing another adapter for other web applications.

> When the web application receives Destroy message (destroy method is
> called) it invokes shutdownHook of proxool facade. The fail-over is
> not responsibility of proxool unless it happens inside of proxool. 

"Fail-over"?

> If mentioned above web application has failed the proxool should
> receive the same shutdown message (facade shutdownHook is called) or
> another message like reinitialize the pools or what is most fit the
> requirements.

Andrew, you're going to have to resort to specifics here. This is all a
bit vague. I think the API already supports shutdown; the exact
mechanism of that shutdown must depend on the environment that Proxool
is running in.

In what way do you think current Proxool API limits you? 

(BTW, Andrew, can you include a subject in your messages to this list
please.)

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] New listener stuff

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

Chr,

On Fri, 2003-02-07 at 02:02, Christian Nedregaard wrote:

> The new classes consists of an abstract generic listener container
> that supports concurency with a read/write lock pluss concrete
> implementations for each listener type. 

Great stuff chr.

> Bill - There is one test failure at the moment:
> 1) testConfigurator(org.logicalcobwebs.proxool.configuration.ConfiguratorTest junit.framework.AssertionFailedError: adapter.getConnectionPoolDefinition() is null
> 
> ...I hope this is not my fault =8-0

No. The reason it happens is that that tests uses a pool that has been
registered and removed. When I changed the alias used in that test from
"template" to "configurator" it worked fine. 

We *should* be able to register, remove and then re-register a pool so I
have written a new unit test for exactly that. This showed that the
Properties are not used when you re-register (so the connection to
hsqldb fails because the user is not set). It is now fixed.

> I've also added a new "util" package for generic utils that might be
> required outside of the main proxool package. I've moved FastArrayList
> there.

Good.

Bill

[Proxool-developer] (no subject)

[Andrew B. <ne...@my...>]

Hello all

>
>
>> In case of the servlet engine I would sugest a Proxool Control Panel
>> having a form of servlet and swing application or a java bean with UI
>> customizer.  =20
>
>
> Are we getting into jmx territory here?
> =20
>
We could touch this. I don't see any problems. The main competitor of Proxo=
ol - PoolMan was jmx compatible.

>  http://java.sun.com/products/JavaManagement/
>
> We might end up righting a JMX component sometime.
>
> =20
>
>> What I meant exactly is how Proxool react to framework state changes.
>>  =20
>
>
> What sort of state changes are you thinking of? I can think of 1)
> Configuration, 2) Shutdown.
>
> We now have that behaviour with ServletConfigurator and
> AvalonConfigurator. The API already allows you to do all these things,
> no?
> =20
>
Let's say we provide few reactions of proxool which are supposed to be mapp=
ed by framework proxy on framework's events. E.g.: we use a proxool insid=
e of web application and we have to close connections on destroying of th=
is application. We cannot wait for JVM shutdown. In this case web applica=
tion is the framework in which the proxool is nested. Not the servlet eng=
ine! When the web application receives Destroy message (destroy method is=
 called) it invokes shutdownHook of proxool facade. The fail-over is not =
responsibility of proxool unless it happens inside of proxool. If mention=
ed above web application has failed the proxool should receive the same s=
hutdown message (facade shutdownHook is called) or another message like r=
einitialize the pools or what is most fit the requirements.

Andrew

[Proxool-developer] New listener stuff

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

I've checked in the new listener code.

New classes:
org.logicalcobwebs.proxool.util.ListenerContainerIF
org.logicalcobwebs.proxool.util.AbstractListenerContainer
org.logicalcobwebs.proxool.util.ReadWriteLock (from Avalon Excalibur)
org.logicalcobwebs.proxool.CompositeConfigurationListener
org.logicalcobwebs.proxool.CompositeConnectionListener
org.logicalcobwebs.proxool.CompositeStateListener
org.logicalcobwebs.proxool.monitor.CompositeStatisticsListener

Changed classes:
org.logicalcobwebs.proxool.ConnectionPool.
org.logicalcobwebs.proxool.ProxoolFacade.

The new classes consists of an abstract generic listener container that supports concurency with a read/write lock pluss concrete implementations for each listener type. 

I have not added tests yet, but they seem to pass the current tests.

I will add tests if you ok my apporach with the listeners.

Bill - There is one test failure at the moment:
1) testConfigurator(org.logicalcobwebs.proxool.configuration.ConfiguratorTest junit.framework.AssertionFailedError: adapter.getConnectionPoolDefinition() is null

...I hope this is not my fault =8-0

I've also added a new "util" package for generic utils that might be required outside of the main proxool package. I've moved FastArrayList there.

CHR

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

Re: [Proxool-developer] Bug 673073 (was no subject)

[Martin C. <mus...@us...>]

> Are we getting into jmx territory here?
> 
>   http://java.sun.com/products/JavaManagement/

Yes, we are getting dangerously close;)

> What sort of state changes are you thinking of? I can think of 1)
> Configuration, 2) Shutdown.

3) Stats

4) Fail-over, redirecting URLs (ok maybe still configuration), but this
was a cool idea!

Martin

Re: [Proxool-developer] Bug 673073 (was no subject)

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

Hi Andrew,

On Wed, 2003-02-05 at 16:10, Andrew Budarevsky wrote:

> In case of the servlet engine I would sugest a Proxool Control Panel
> having a form of servlet and swing application or a java bean with UI
> customizer. 

Are we getting into jmx territory here?

  http://java.sun.com/products/JavaManagement/

We might end up righting a JMX component sometime.

> What I meant exactly is how Proxool react to framework state changes.

What sort of state changes are you thinking of? I can think of 1)
Configuration, 2) Shutdown.

We now have that behaviour with ServletConfigurator and
AvalonConfigurator. The API already allows you to do all these things,
no?

-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] (no subject)

[Andrew B. <ne...@my...>]

Hello Bill!

Finally I have solid keyborad to type ;) I hate laptop's one ;)

> Please don't be confused with event term. Destroy method is actually
> the event the servlet receives on container state change.

>>I see. So you mean a servlet that would implement the >>destroy method an=
d
>>perhaps help to make configuration easier? I like >>that. We already (in
>>0.7) have a MonitorServlet; why not have another >>servlet for other
>>tasks. Like:

>>1. Shutting down Proxool

>>2. Configuring Proxool from file

I didn't mean any certain form of framework. The servlet container is one o=
f possible. Let it be. Again, in my case I have framework of absolutely d=
ifferent kind. In case of the servlet engine I would sugest a Proxool Con=
trol Panel having a form of servlet and swing application or a java bean =
with UI customizer. This one should connect proxool or to be forked as a =
thread. It shows real-time statistics, may configure a statistics log for=
mat. In case of Avalon framework this component could be different but st=
ill play the same role. But that's all about proxool tuning. What I meant=
 exactly is how Proxool react to framework state changes. There are few w=
ays to use proxool in servlet container. It may be a singleton serving al=
l servlets and it may be a part of one web application serving the needs =
of this web application. This is the design issue. It is not possible to =
say for sure which way is preferable. I would say that both are. It depen=
ds upon   technical requirements. So that I assume proxool is a component=
 allowing to be nested within a custom framework. To pass on framework ev=
ents the framework should provide a proxy in between, talking directly to=
 proxool. If the framework doesn't suppose proxool customization it uses =
it transparently like we have already discussed.  

Regards,
Andrew.

RE: [Proxool-developer] Bug 673073

[Martin C. <mus...@us...>]

Ok I'm not entirely done my conversation here, but obviously the
timezone difference has put me behind;)

I'm not sure if I "totally" like the idea of again putting this on the
web application shoulders. The ServletConfiguration should run as an
individual monitor application separte from the applications, and
support all instances of proxool. I have an idea how this could work,
but it's a bit complex so really comments are welcome, and please bare
with me, I haven't had my morning coffee.

Could we make the proxool distribution for web containters in two parts
(or actually three). The first distribution would be a lean and mean
"controller" distribution that sits in the commons. All it would do is 
handle registration/deregistration of new pools, manage pools for the
same connection across applications, support redirecting configuration
to the individual pools, and of course manage starting them up/shutting
them down. 

The implementation goals would *have to be* that: 
a) We keep this controller lean and mean (i.e. the less features the
better)

b) remove all external dependencies 

c) be extremely careful of the method calls made to registered proxool
pools, to support backward compatibility in the future and avoid
MethodNotFoundExceptions.

The second distribution is just your standard proxool package, which
also now has the ability to recognise and register with the controller.
The commons-logging, and JDBC driver would be deployed here.

The third distribution would be your ServletConfiguration WAR, which
uses the controller to inspect the various running pools.

Eeek... perhaps a little too complex. I can already see flaws as I
re-read this too. But this would give yor WARs complete independence
from the proxool code. Also the managing of all pools from a single
Servlet is powerful (didn't Bill suggest making proxool one day a
fail-over solution;)

Two other feedbacks from previous posts:

- DataSource is a Good Thing (tm)

- Refactor logging code a Good Thing Too (unregistered)

Ok, I've done make wild and crazy suggestions. Back to my DocBook...
Martin

On Wed, 2003-02-05 at 10:14, Bill Horsman wrote:
> On Wed, 2003-02-05 at 14:57, Christian Nedregaard wrote:
> 
> > Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7.
> 
> And I've just committed it. This was Andrew Budarevsky's idea. To
> configure Proxool and to get it to shutdown correctly you just need to
> add something like this to your web.xml:
> 
> <servlet> 
>   <servlet-name>ServletConfigurator</servlet-name> 
>   <servlet-class>org.logicalcobwebs.proxool.configuration.ServletConfigurator</servlet-class> 
>   <init-param> 
>     <param-name>xmlFile</param-name> 
>     <param-value>WEB-INF/proxool.xml</param-value> 
>   </init-param> 
> </servlet> 
> 
> If, for any reason, you don't want it to autoShutdown you can add:
> 
>   <init-param> 
>     <param-name>autoShutdown</param-name> 
>     <param-value>false</param-value> 
>   </init-param> 
> 
> I'm going to be busy documenting the conclusions (?) from these
> discussions now :( I'll post something on
> http://proxool.sourceforge.net/dev (which is where I put draft
> documentation prior to a release).