The "ran out of parsers" happened to me with Vel 0.7, I sent a patch
adding the finally clause. The problem occured when there was some
parser error that then failed to recycle the parser into the pool
(e.g. a "$" or a single-line comment at the end of the file withoput
an EOL, etc.). These parser problems have also been fixed on 0.75ff.
Check your log for parser errors...
The runtime now allows creating additional parsers on the fly. See
the error message generated on line 600 of Runtime.java (asking
you to increment the parser.pool.size property).
This problem should be therefore fixed in Velocity 1.0.
:) Christoph
Costas Stergiou wrote:
>
> Actually, once this error occured, nothing worked after that. I had to
> restart tomcat. I don't really have a large number of concurrent users,
> I only have quite big templates.. (many many loops, etc).
> I think that this pool may have a leak somewhere, e.g. something is not
> returned/released correctly.
> Also, once this error occured, it appeared in all templates (even the
> simplest ones, e.g. navigations (in Turbine world).
>
> The point I am worried so much is that we now build an application
> based on velocity that is expected to have thousands of concurrent
> users (it may grow too popular) and it's all based on Turbine+Velocity.
> It is important to know if there is any problem here (the investmenet
> is very big).
> Thanks,
> Costas
>
> ----- Original Message -----
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 17, 2001 11:29 AM
> Subject: Re: Strange Exception with velocity
>
> > Costas Stergiou wrote:
> > >
> > > What do you mean that "I have run out of parsers"? Why this error
> > > occured only after a significant usage time? Does it have to do with
> memory
> > > consumption?
> > > Is it bad design of my code?
> > >
> > > I can update to the 1.0 version if this is a problem that is solved
> there,
> > > no problem.
> > > I just want to know if this is something that I can be sure that it will
> not
> > > happen
> > > again since this is a very critical system.
> > > Thanks,
> > > Costas
> > >
> >
> > The pool that we use to store the parsers is not very smart (SimplePool
> > :-))
> > and possibly during a high period of concurrency you ran out of parses.
> > The pool is initialized with a fixed number of slots and simply returns
> > null if it has nothing left to give. Do you experience high levels
> > of concurrency?
> >
> > There is a little fix in recent versions of Velocity that detects a
> > null coming back from the parser pool and re-creates the pool for you
> > and logs an error. We will find a better pool implementation, probably
> > something from the jakarta commons, but what's there works.
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > [EMAIL PROTECTED]
> >
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/turbine
> > http://tambora.zenplex.org
--
==============================================================
Deutsches Zentrum fuer Luft- und Raumfahrt (DLR)
Deutsches Fernerkundungs Datenzentrum (DFD)
DLR-DFD, Muenchner Strasse 20, D-82234 Wessling, Germany
============= Currenlty relocated to ESA-ESRIN ===============
ESA ESRIN Tel: +39 06 941 80 589
c/o Christoph Reck (DLR) Fax: +39 06 941 80 512
Via Galileo Galilei mailto:[EMAIL PROTECTED]
I-00044 Frascati (Roma) http://www.dfd.dlr.de
==============================================================
