You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/03/14 15:26:05 UTC
"startup order", was: [Vote]: New Release
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 14.Mar.2002 -- 09:14 AM, Carsten Ziegeler wrote:
> > Hi Team,
> >
> > let's try to get closer to the "release often, release early" theme.
> >
> > Vadim and I propose to make a code freeze now or feature stop now
> > and make a "bug fix/doc update" phase for some time (one week or so)
> > and then release a new version.
> >
> > So, please state your opinion.
>
> Carsten,
> +1 but one serious problem should be fixed first: since the HSQLDB
server
> is made a avalon component but never used as such, it is not
guaranteed
> that it is started before a connection is attempted to it.
Chris,
The more I think about issue you found... The more I'm sure that the
problem is not in the order (also I agree - sometimes order could be of
importance), but in the way how JDBC pool is being created. I think pool
should be more resilient to the temporary network issues, and it should
try to create connections, till success, with some time interval.
Common example of why this is required: if tomcat and Oracle are started
on the same machine as services, and *even* if you have correct service
startup order (tomcat depends on oracle), still tomcat will come up
before than oracle mounts its database. If this is installed on
different machines though, the requirement to have self-healing pools is
even more important.
What do you think?
Vadim
>
> It looks like I am the only one who has (knowingly) experienced
this
> problem but it has been sheer luck that it is not more widespread.
> Although on identifying the problem I have dived into the startup
code,
> I don't know enough to come up with a good solution for this.
>
> Chris.
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
JDBC startup, was: "startup order"
Posted by Vadim Gritsenko <va...@verizon.net>.
To avalon guys:
In Cocoon, we have an issue with unattended server (re)starts, were it
is more than possible that Tomcat/Cocoon are initialized well before
Oracle (or other DB) mounts it database, which is leading to JDBC pool
not being initialized because of connection issues.
Can something be changed in the way how JDBC connection pool is being
created?
Thanks in advance...
Below is the discussion we had on the cocoon dev list:
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 14.Mar.2002 -- 09:26 AM, Vadim Gritsenko wrote:
> > > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> > > +1 but one serious problem should be fixed first: since
> > > the HSQLDB server
> > > is made a avalon component but never used as such,
> > > it is not guaranteed that it
> > > is started before a connection is attempted to it.
> >
> > Chris,
> >
> > The more I think about issue you found... The more I'm sure that the
> > problem is not in the order (also I agree - sometimes order could be
of
> > importance), but in the way how JDBC pool is being created. I think
pool
> > should be more resilient to the temporary network issues, and it
should
> > try to create connections, till success, with some time interval.
> >
> > Common example of why this is required: if tomcat and Oracle are
started
> > on the same machine as services, and *even* if you have correct
service
> > startup order (tomcat depends on oracle), still tomcat will come up
> > before than oracle mounts its database. If this is installed on
> > different machines though, the requirement to have self-healing
pools is
> > even more important.
> >
> > What do you think?
>
> Vadim, I admit that my concern is quite short sighted :-) Actually, I
> _believe_ Avalon's Connection Pools do reconnect if for some reason or
> other connections are lost. But they don't like that to happen on
> startup. Failing early is a good concept because it eases bug hunting.
Early failing could be substituted by early warning... ;)
> If not for this reason one might want to ask why connect to the DB
> before a connection is requested anyways? So I wouldn't go for
repeated
> tries to connect but connect as late as possible.
>
> Unattended server starts are definately an issue.
And automatic re-starts!
> So, shall we escallate this issue to avalon-dev, then?
Ok.
> BTW ExcaliburComponentManger does some good magic to initialize
> components in correct order.
AFAIU, Only if component lookups other component in its compose()
method, which is not the case for JDBC connections and HSQLDB server.
Vadim
> Can't know about HSQLDB, though.
>
> Cheers,
> Chris.
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: "startup order", was: [Vote]: New Release
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 14.Mar.2002 -- 09:26 AM, Vadim Gritsenko wrote:
> > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> > +1 but one serious problem should be fixed first: since the HSQLDB
> server
> > is made a avalon component but never used as such, it is not
> guaranteed
> > that it is started before a connection is attempted to it.
>
> Chris,
>
> The more I think about issue you found... The more I'm sure that the
> problem is not in the order (also I agree - sometimes order could be of
> importance), but in the way how JDBC pool is being created. I think pool
> should be more resilient to the temporary network issues, and it should
> try to create connections, till success, with some time interval.
>
> Common example of why this is required: if tomcat and Oracle are started
> on the same machine as services, and *even* if you have correct service
> startup order (tomcat depends on oracle), still tomcat will come up
> before than oracle mounts its database. If this is installed on
> different machines though, the requirement to have self-healing pools is
> even more important.
>
> What do you think?
Vadim, I admit that my concern is quite short sighted :-) Actually, I
_believe_ Avalon's Connection Pools do reconnect if for some reason or
other connections are lost. But they don't like that to happen on
startup. Failing early is a good concept because it eases bug hunting.
If not for this reason one might want to ask why connect to the DB
before a connection is requested anyways? So I wouldn't go for repeated
tries to connect but connect as late as possible.
Unattended server starts are definately an issue.
So, shall we escallate this issue to avalon-dev, then?
BTW ExcaliburComponentManger does some good magic to initialize
components in correct order. Can't know about HSQLDB, though.
Cheers,
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org