Webware for Python

On Wed, 2002-09-25 at 07:16, Max Ischenko wrote:
> I have a problem: sometimes my servlet got request which it couldn't
> handle in a finite time. This leads to the situation when whole
> appserver becomes unavailable and just "hangs", not responding to new
> requests.

What kind of processing is going on at this time?  It sounds like the
long-running code is holding onto the GIL (global interpreter lock), and
not letting other threads continue.  If this is the case, I think the
only solution is to run that in another process.

> Is it possible to "stop" the servlet after a given amount of time
> passed? Or should I use a timer inside my servlet to stop the
> processing?

Well, I suspect your servlet isn't being run either, if the rest of the
system is also not available.  So the servlet couldn't really monitor
the processing.

> PS: I'm using 0.7 release.
> Should I stay with it or upgrade to stable CVS snapshot.

I don't think there's any changes related to this in CVS.

  Ian

Ian Bicking wrote:

> On Wed, 2002-09-25 at 07:16, Max Ischenko wrote:
> > I have a problem: sometimes my servlet got request which it couldn't
> > handle in a finite time. This leads to the situation when whole
> > appserver becomes unavailable and just "hangs", not responding to new
> > requests.
> 
> What kind of processing is going on at this time?  It sounds like the
> long-running code is holding onto the GIL (global interpreter lock), and
> not letting other threads continue.  If this is the case, I think the
> only solution is to run that in another process.

The exact situation is not clear to me yet.
In summary, job of the servlet is to fetch some data from RDBMS
(using pyPgSQL driver), format it into XML and pass to the client.

When requested dataset is too much, something bad is happens and can't
figure what it is exactly. It seems like my servlet doesn't notice when
DBMS finally finished serving SQL and it continues to wait for something
(forever) while postmaster has returned to idle. Moreover, AppServer is
lock as well (as I said earilier).

Not-so-lengthy requests are handled just fine.

-- 
Bst rgrds, M.A.X.: Mechanical Artificial Xenomorph.

On Thu, 2002-09-26 at 02:28, Max Ischenko wrote:
> When requested dataset is too much, something bad is happens and can't
> figure what it is exactly. It seems like my servlet doesn't notice when
> DBMS finally finished serving SQL and it continues to wait for something
> (forever) while postmaster has returned to idle. Moreover, AppServer is
> lock as well (as I said earilier).
> 
> Not-so-lengthy requests are handled just fine.

I don't know Postgres very well, but MySQL lets you limit the size of
the response by ending your select with "limit 100" (or whatever size).

I suspect the problem is with the adapter.  The Postgres adapters in
particular seem to have caused lots of problems.  I would try doing the
same query from a simpler Python program, and seeing what happens.

  Ian

Ian Bicking wrote:

> On Thu, 2002-09-26 at 02:28, Max Ischenko wrote:
> > When requested dataset is too much, something bad is happens and
> > can't figure what it is exactly. It seems like my servlet doesn't
> > notice when DBMS finally finished serving SQL and it continues to
> > wait for something (forever) while postmaster has returned to idle.
> > Moreover, AppServer is lock as well (as I said earilier).
> > 
> > Not-so-lengthy requests are handled just fine.
> 
> I don't know Postgres very well, but MySQL lets you limit the size of
> the response by ending your select with "limit 100" (or whatever size).
> 
> I suspect the problem is with the adapter.  The Postgres adapters in
> particular seem to have caused lots of problems.  I would try doing the
> same query from a simpler Python program, and seeing what happens.

I've misguided you, sorry.

In reality there is not big single queries, but alot of small ones.
For exmaple, gathering information about single Point-of-Sale-Terminal
session requeires issuing ~10 SQL queires which takes about 4 seconds
to comlete. While number of sessions is constrained by id or date all is
fine. But when someone tries to get info about all sessions (> 1000) the
system is choked.

-- 
Bst rgrds, M.A.X.: Mechanical Artificial Xenomorph.