Why are attributes not supported in the ServletContext (alias
HttpServer) in Jetty -2.1.x ?

Isn't it just a simple dictionary ?

- Jesper
--
CAPUT              Jesper Jørgensen       Phone  +45 3312 2442
Nygade 6           Product Manager        Fax    +45 3391 2442
DK-1164 Kbh K      jesper@...       http://www.caput.com

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

DOH!

I implemented a file cache and regular runfinalization - it made no
difference!   So I've looked again for the file leak and found it
in LookAndFeelServlet.

So Jetty does not suffer from this problem, only my demo servlets.

Fixed next release.....

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395



------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

4From Greg Wilkins
> I guess it would also be possible for the com.mortbay.Jetty.Server
> class to start the server then block on System.in until it received
> any input and then gently exit??  This is a bit of a hack, but I
> guess this reflects a larger problem of how java services should be
> installed in various OS's for startup and shutdown.
>
> I'd be interested to hear from anybody else who has a way of doing
> this that may be considered cross-platform.

I did something similar for a server that was meant to run on either Windows
NT or Unix.  The after launching the child processes (Unix) or threads (NT),
the main thread sat blocked on a read/eval/print loop on standard input.
The (few) commands understood were for debugging, and EOF caused the main
thread to terminate all children and exit.

One nice aspect was that all the NT-specific code to run as an NT service
was in a seperate executable.  The service adaptor took care of all the
interactions with NT service manager, captured standard output and standard
error, and wrote to the event log.  The service adaptor launched the server
much as you would from the command line.  The server was terminated by
closing the pipe attached to standard input.

This simplified debugging, as to the server running from the command line
(NT or Unix) or running as an NT service looked exactly the same.


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

As I have previously mentioned, Jetty runs out of open files under
heavy load.   My simple analysis using lsof has shown that it is
the FileHandler that is "collecting" file handlers until they
are garbage collected.

I'm not sure if the open files are from the FileInputStream or
the File instance itself.  However I close the FileInputStream
and have tried calling finalize on the stream and the file,
but the underlying file is still not closed until GC time.

Does anybody know of a way to force the underlying file descriptor
to be closed?  I don't really want to force System finalization for
each request as that will surely be some overhead, but maybe
force it after every N requests???

Does System.runfinalization() only finalize known zero reference
objects or does it evaluate GC code looking for unreferenced
goups of objects.   If it is the former, it may not be too bad to
call frequently?

The only other thing that I can think of that may help with this
situation is to implement a FileCache in the FileHandler.   If files
can be served out of the cache, then additional file descriptors should
not be needed to server them.  This is probably a good idea anyway,
although it would be much easier to implement with Java2 references.

Comments and/or ideas????

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Release 2.2.Beta2 is now available at http://205.147.239.15

Release 2.2.Beta2 - 12 June 1999
   + Added all write methods to HttpOutputStream$SwitchOutputStream
   + Added com.mortbay.Jetty.Server.shutdown() for gentler shutdown
     of server. Called from Exit servlet
   + HttpRequest.getParameterNames() no longer alters the order
     returned by getQueryString().
   + Handle  path info of a dynamic loaded servlets and
     correctly set the servlet path.
   + Standardized date format in persistent cookies.

We have now got control of our domain name back from our old provider
and hopefully the domain will move to the new IP in the next few days.
Any email that you sent us that you think may have got lost should
be resent after that.

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Kent Johnson wrote:

> >Juans analysis found a few hot spots that could be optimized:
> > + FilterOutputStream spent lots of time breaking byte arrays into
> >   single calls to write(byte).   I'm not exactly sure where this
> >   could have happened as I implement all the FilterOutputStream
> >   write methods.  However it prompted me to rewrite HtmlFilter
> >   in 2.2.B1
> A while ago I saw this happening in
> HttpOutputStream.SwitchOutputStream. I mentioned it to you, but maybe
> it slipped through the cracks. Here is the note I sent before:

DOH!  Both you and Juan told me "FilterOutputStream in HttpOutputStream.
SwitchOutputStream", but I only saw FilterOutputStream and forgot about
the one in HttpOutputStream.  So I have be staring at Htmlfilter
wondering how it get through to the the write(byte b[], int off, int len)
method.....

Oh well, at least that got an optimize as well....

B2 out in 5...

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

i have noticed that there might be a little error in the handle method
of ServletHandler:
when a new servlet is dynamicly loaded
...
holder.setAutoReload(autoReloadDynamicServlets);
servletMap.put(PathMap.match(pathSpec,address)+servletClass+"%",
			    holder);

// service request
request.setServletPath(pathSpec); <--- wrong Servlet path in the first call?
holder.service(request,response);
...

greetings klaus



------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Greg,

Thanks for the info.

> > I'm curious, what inefficiencies are you talking about? Did these
> > changes make it into the distribution? I didn't see anything about it.
>
>Juans analysis found a few hot spots that could be optimized:
>
> + FilterOutputStream spent lots of time breaking byte arrays into
>   single calls to write(byte).   I'm not exactly sure where this
>   could have happened as I implement all the FilterOutputStream
>   write methods.  However it prompted me to rewrite HtmlFilter
>   in 2.2.B1

A while ago I saw this happening in
HttpOutputStream.SwitchOutputStream. I mentioned it to you, but maybe
it slipped through the cracks. Here is the note I sent before:

==========

I have been looking at Jetty in OptimizeIt and made an interesting discovery.
Running under NT 4.0, I found that adding the definition

      public void write(byte b[], int off, int len) throws IOException {
          out.write(b, off, len);
      }

to HttpOutputStream.SwitchOutputStream can double the speed of file transfers
from Jetty. I measured this by opening a 15MB movie file in Netscape
on the same
machine that is running the server. Without the patch the transfer rate usually
peaked around 400-500K bytes/sec; with the patch it always got over 500K and
sometimes up to 900K bytes/sec.

The reason is it avoids calling FilterOutputStream.write(byte b[], int off, int
len), which does a byte-by-byte copy of the input buffer to out.

One strange aspect is that doing the same test on a Mac server, the changed
version is about half as fast as the original. I hove no idea why. So I have
patched it on the NT version only.

You might want to try this on your servers and add the change if you think it
helps.

==========

Kent




------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Kent Johnson wrote:
> I am running Jetty on Windows NT. The only user interface to the
> server is the console, which shows the log. To quit the server, I
> type control-C.

I've implemented an Exit servlet so that http://hostname:8080/Exit
calls the new gentle shutdown method.

I guess it would also be possible for the com.mortbay.Jetty.Server
class to start the server then block on System.in until it received
any input and then gently exit??  This is a bit of a hack, but I
guess this reflects a larger problem of how java services should be
installed in various OS's for startup and shutdown.

I'd be interested to hear from anybody else who has a way of doing
this that may be considered cross-platform.

regards

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Kent Johnson wrote:
> Juanco wrote:
> >I forgot to mention the last result of my application of NuMega TrueTime to
> >Jetty. After removing the inefficiencies of FilterOutputStream
>
> I'm curious, what inefficiencies are you talking about? Did these
> changes make it into the distribution? I didn't see anything about it.

Juans analysis found a few hot spots that could be optimized:

  + ThreadPool and ThreadedServer maintained a pool of idle threads
    and busy threads would return to the idle pool before getting the
    next job.   Juan provided an implementation that I adapted and put
    in 2.2.B1 where the jobs were queued and the threads looped taking
    jobs out of the queue.  This gives much better worse case performance
    at little or no loss to latency of an idle server (may be better as
    I can now have a minimum pool of threads).

  + FilterOutputStream spent lots of time breaking byte arrays into
    single calls to write(byte).   I'm not exactly sure where this
    could have happened as I implement all the FilterOutputStream
    write methods.  However it prompted me to rewrite HtmlFilter
    in 2.2.B1

  + Time was spent formatting dates in Log.  Again -this may have been
    an old version of Jetty, but it prompted me to update log in 2.2.B1
    It now either uses the date in the request, or if a date format is
    configured it uses the DateCache class (inspired by Kent after an
    earlier analysis) to format the date.

I have yet to here back how these fixes have gone under NiMega TrueTime.
However, I do believe that a few performance problems still exist:

  + under heavy load of the full demo, Jetty sometimes runs out of
    files descriptors (too many open files).  Thus I think that it must
    not be closing all the files/sockets when it can and is relying on
    the GC to get them.   I have fixed several of these problems and
    2.2.B1 does not have this problem in the core server, but some of
    the demo handlers/servlets must.

  + Performance and memory size appear to decrease/increase after
    receiving requests before reaching plateau at about 70% of the
    initial throughput.   Could be JVM problems, but it needs further
    analysis.


Stay tuned for 2.2.B2 later tonight -

   + Added com.mortbay.Jetty.Server.shutdown() for gentler shutdown
     of server. Called from Exit servlet
   + HttpRequest.getParameterNames() no longer alters the order
     returned by getQueryString().
   + Handle / in path info of dynamic loading of servlets.
   + Standardized date format in persistent cookies.


--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Juanco wrote:

>I forgot to mention the last result of my application of NuMega TrueTime to
>Jetty. After removing the inefficiencies of FilterOutputStream

I'm curious, what inefficiencies are you talking about? Did these
changes make it into the distribution? I didn't see anything about it.

Kent

Kent Johnson                   Transparent Language, Inc.
kjohnson@...       http://www.transparent.com



------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

I am running Jetty on Windows NT. The only user interface to the
server is the console, which shows the log. To quit the server, I
type control-C.

I would like to do an orderly shutdown of the server. Using
control-C, the server process just gets killed.

Is there a better way to do this? Some way to intercept control-C?
Some way to get key events without putting up a window? I know I
could put up a window with a shutdown button in it, but that seems
kind of strange when there is no other GUI in the server.
Kent Johnson                   Transparent Language, Inc.
kjohnson@...       http://www.transparent.com



------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

juanco wrote:
> This is something that could be easily solved by using the Java 1.2
> collections OrderedMap instead of Hashtable.

As much as I would like to start using collections - I think it is best
to wait some time yet.  While I could use the 1.1 version of the
collections - I really don't want to do this as:

  + Extra 200K (20%) on the distribution size.
  + Extra impact on the memory foot print.
  + Hopefully Java2 will be deploy commonly sooner rather than
    later - so I'd prefer to go straight to the final version.
  + While the new collections look really cool, I'd like to get
    some more experience using them before risking mistakes in
    Jetty.

Brett Sealey wrote:
> Jetty-2.2.B1
> One to watch out for when using a HttpServletRequest:
>
> A side effect of a call to getParameterNames() is that the order of the
> query arguments returned by getQueryString() may be changed even though
> you haven't fiddled them.

Geeeze  -  OK I've added getParameterNames to URI, so that HttpRequest can
implement getParameterNames without calling URI.getParameters() and hence
setting the modified flag.

But if you mess with the parameters, the order may change (until we all
are running Java 2)

regards

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

-----Original Message-----
From: Brett Sealey [mailto:brett@...]
Sent: Thursday, June 10, 1999 5:30 AM
To: Jetty Discussion
Subject: [jetty-discuss] getQueryString() roulette

Jetty-2.2.B1 One to watch out for when using a HttpServletRequest: A side effect of a call to getParameterNames() is that the order of the query arguments returned by getQueryString() may be changed even though you haven't fiddled them. Cause? Well, a call to getParameterNames() sets the underlying URI as modified and so it is reconstructed via an unordered Hashtable. This doesn't happen on initial construction so the URI starts out as the exact string of what went in. This probably happens in other cases as well. So, the moral of the story is get in early if you want to see the exact query string sent by the client in the first place... btw, I know I shouldn't really care about the order but you know how it is... :-) Cheers, Brett Sealey brett@... Locked Bag 6581 GPO Sydney NSW 1100 Australia 2nd Floor 175 Liverpool St. Sydney NSW Ph: +61 2 9206 3426 Fax: +61 2 9281 1301

---

eGroups now offers FREE email newsletters! Women.com, RollingStone, Travelocity, and more… Sign-up Now!

For the latest information about Jetty, please see http://www.mortbay.

Jetty-2.2.B1

One to watch out for when using a HttpServletRequest:

A side effect of a call to getParameterNames() is that the order of the
query arguments returned by getQueryString() may be changed even though
you haven't fiddled them.

Cause? Well, a call to getParameterNames() sets the underlying URI as
modified and so it is reconstructed via an unordered Hashtable. This
doesn't happen on initial construction so the URI starts out as the
exact string of what went in.

This probably happens in other cases as well.

So, the moral of the story is get in early if you want to see the exact
query string sent by the client in the first place...

btw, I know I shouldn't really care about the order but you know how
it is... :-)

Cheers,
Brett Sealey                  brett@...
                               Locked Bag 6581 GPO Sydney NSW 1100 Australia
                               2nd Floor 175 Liverpool St. Sydney NSW
                               Ph: +61 2 9206 3426 Fax: +61 2 9281 1301


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Cookies with future expiry dates are being ignored by Internet
Exploder because the expiry date format is "non-standard".

Server: MortBay-Jetty-2.2.B1
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; SunOS 5.5.1 sun4u; X11)

A fix is the following change to Cookies.java:

brett@peregrin[1199]% diff Jetty-2.2.B1/src/com/mortbay/HTTP/Cookies.java
~/Cookies.java
29c29
<       new SimpleDateFormat("dd MMM yyyy HH:mm:ss 'GMT'");
---
>       new SimpleDateFormat("EEE, dd-MMM-yyyy HH:mm:ss 'GMT'");

The crucial part was the addition of the day-name. The dashes appear
to be optional but are described in:
  http://home.netscape.com/newsref/std/cookie_spec.html

Cheers,
Brett


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Release 2.2.B1 is now available on the new mortbay site:

    http://205.147.239.15/software/Jetty.html

I have no idea when the internic will get around to redelegating the
domain name to the new site...

Most of the work has been in optimization of the thread handling put
into beta0.   There are still some performance instabilities and
object leaks under some virtual machines.  Most disturbing is that
performance appears to decrease after the first couple of hundred
requests?   More analysis is required to determine what is happening
and to check that it is not a problem within the JVM.

Virtual hosts, reload on demand and a portable makefile are next
on the agenda...

Thanks again for all the feedback and contributions.  I have updated
the CONTRIBUTORS.txt file, but please give me a yell if I have not
attributed any credit due.

Release 2.2.Beta1 - 7 June 1999
   + Defined abstract ServletLoader, derivations of which can be
     specified in HttpConfiguration properties.
   + Implemented all HttpServer attribute methods by mapping to the
     HttpConfiguration properties.  Dynamic reconfiguratin is NOT
     supported by these methods (but we are thinking about it).
   + Close files after use to avoid "file leak" under heavy load.
   + Fixed missing copyright messages from some contributions
   + Fixed incorrect version numbers in a few places.
   + Improved ThreadPool synchronization and added minThreads.
   + Allow configuration of MinListenerThreads, MaxListenerThreads,
     MaxListenerThreadIdleMs
   + HtmlFilter optimized for being called by a buffered writer.
   + Don't warn about IOExceptions unless Debug is on.
   + Limit the job queue only grow to the max number of threads.
   + Included GNUJSP 0.9.9
   + Optional use of DateCache in log file format
   + Fixed cache in FileJarServletLoader
   + Destroy requests and responses to help garbage collector.
   + Restructure ThreadedServer to reduce object creation.

Release 2.2.Beta0 - 31 May 1999
   + Servlet loader handles jar files with different files separator.
   + ThreadedServer gently shutsdown.
   + Handle malformed % characters in URLs.
   + Included and improved version of Threadpool for significant
     performance improvement under high load.
   + HttpRequest.getCookies returns empty array rather than null for no
     cookies.
   + Added HttpResponse.requestHandled() method to avoid bug with
     servlet doHead method.
   + Added Page.rewind() method to allow a page to be written multiple
     times
   + Added "Initialize" attribute to servlet configuration to allow
     servlet to be initialized when loaded.
   + LogHandler changed to support only a single outfile and optional
     append.
   + Included contributed com.mortbay.Jetty.StressTester class
   + Token effort to keep test files out of the jar
   + Removed support for STF




--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

klausspd@... wrote:
>
> how about a start/stop (init/destroy) function for the handlers?
>
> i am developing a servlet-based application that needs a database.
> before the first request to the database-servlet i have to establish my
connection-pool (and some more stuff) so the PRELOAD feature for servlets of
some servlet engines is very helpful to start a Managementservlet that is doing
all these jobs.
>
> I have added a preload function to the servlet handler in JETTY 2.1.7 but it
is not perfect, because there is no good place -> no start or init in the
servlethandler (i had to use setServer).
>
> is there a better place or do i have to be just more patient to wait for JETTY
2.3 ?


I've put this in the B1 release which will be available in the next few days.
Pre-load can be controlled from the config file.

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395



------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

---
Juancarlo Añez
Modelistica
mailto:juancarlo@...
http://www.modelistica.com

We have some customers complaining that there log analyzer tool cannot
parse the access log from Jetty (version 2.1.5) due to the date format.
What I know of, the only standard in this area is the NCSA transfer log
format which has a date format like [dd/mmm/yyyy:HH:mm:ss].

I noticed that Jetty simply uses the same format as in the response
header. Has there been any discussion on this matter ?

- Jesper

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

Doyle Davidson wrote:
> In the Jetty 2.2 code:
>
> It appears that the FileHandler.sendFile() method does not close the "File"
> object  after sending it.  I don't see a File.close() call anywhere in the
> source path and I get "read only" errors when attempting to access files that
> have been served up (this is on a Windows 98 machine).
>
> It would seem to me that a try/catch/finally clauses should be added around
the
> "response.writeInputStream(in,len);" call to do a "in.close();" in the finally
> section.
>
> Otherwise, I suppose handles are not closed until garbage collection.
>
> Am I missing something?
> I also see the same thing in the "Server" main class when it reads the config
> file.

Doyle,

right you are - this also has the nasty side effect of making the server
run out of files (too many open files) when under heavy load.  I meant to
fix that in 2.2.B0, but it slipped past.  Will be fixed in 2.2.B1

NB.  I've been loosing email for the last 2 weeks and my ISP just found it
all - so I have several hundred emails to wade through before working on
B1 so don't hold your breath...

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

> The links from the Jetty page on that server are broken for me. (Could
> just be a local DNS problem.)
>
> So if it doesn't work for you, do what I did and use
> ftp://205.147.239.15/pub/ instead.

Thanks Brett,

This should be fixed now (I've hardcoded the IP address).  Still no
progress on the domain name redelegation....

-gregw


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.

The links from the Jetty page on that server are broken for me. (Could
just be a local DNS problem.)

So if it doesn't work for you, do what I did and use
ftp://205.147.239.15/pub/ instead.

Cheers,
Brett Sealey                  brett@...
                               Locked Bag 6581 GPO Sydney NSW 1100 Australia
                               2nd Floor 175 Liverpool St. Sydney NSW
                               Ph: +61 2 9206 3426 Fax: +61 2 9281 1301

On Mon, 31 May 1999, Greg Wilkins wrote:

>
> Jetty 2.2.Beta0 is available at http://205.147.239.15.    Note that this
> address will soon be delegated to www.mortbay.com.


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

Jetty 2.2.Beta0 is available at http://205.147.239.15.    Note that this
address will soon be delegated to www.mortbay.com.

Release 2.2.Beta0 - 31 May 1999
   + Servlet loader handles jar files with different files separator.
   + ThreadedServer gently shutsdown.
   + Handle malformed % characters in URLs.
   + Included and improved version of Threadpool for significant
     performance improvement under high load.
   + HttpRequest.getCookies returns empty array rather than null for no
     cookies.
   + Added HttpResponse.requestHandled() method to avoid bug with
     servlet doHead method.
   + Added Page.rewind() method to allow a page to be written multiple
     times
   + Added "Initialize" attribute to servlet configuration to allow
     servlet to be initialized when loaded.
   + LogHandler changed to support only a single outfile and optional
     append.
   + Included contributed com.mortbay.Jetty.StressTester class
   + Token effort to keep test files out of the jar
   + Removed support for STF

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

how about a start/stop (init/destroy) function for the handlers?

i am developing a servlet-based application that needs a database.
before the first request to the database-servlet i have to establish my
connection-pool (and some more stuff) so the PRELOAD feature for servlets of
some servlet engines is very helpful to start a Managementservlet that is doing
all these jobs.

I have added a preload function to the servlet handler in JETTY 2.1.7 but it is
not perfect, because there is no good place -> no start or init in the
servlethandler (i had to use setServer).

is there a better place or do i have to be just more patient to wait for JETTY
2.3 ?

greetings




------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

<7imn08$84h-@egroups.com> wrote:
Original Article: http://www.egroups.com/group/jetty-discuss/?start=4
> when i was using the jdbc package whith the odbc driver, i noticed that after
doing some queries
> the used memory is increasing until the system crashs even if you ask the
system to do a gc().
> ...

> so my question is if i am doing something wrong or if there is has a
> better solution for that problem?

No you are not doing anything wrong. The JDBC classes are much in need of
a major rework.  The approach taken is simply not the right way to go,
subclassing the JDBC classes causes many problems not the least not working with
JDBC.

We will soon be doing a moderate overhaul of these classes and hope to
completely redo the connection pool, as well as give greater assistance
of mapping objects to tables and vice versa.

So if you have any other feedback on these classes, we are very keen to
hear it.

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

when i was using the jdbc package whith the odbc driver, i noticed that after
doing some queries
the used memory is increasing until the system crashs even if you ask the system
to do a gc().

after some testing i figured out that closing the connection (that stays usually
open in the pool) the system
gets the memory back.
i have read some documentation from sun and noticed that you can not rely on the
finalizing methods of
all the jdbc objects for cleaning the memory.

so i identified the Statement object in com.mortbay.JDBC.Database.query:
...
>>>   java.sql.Statement s = connection.createStatement();
            java.sql.ResultSet rs= s.executeQuery(query);

            com.mortbay.JDBC.ResultSet result =
                                  new com.mortbay.JDBC.ResultSet(rs,connection);
             return result;
...
this one is never closed, so the system keeps all the memory.
just for testing i have changed com.mortbay.JDBC.ResultSet to remember not only
the connection it is using but also the statement. when this ResultSet is closed
or finalized
the Statement is closed as well.

     public void finalize()
     {
         if (connection!=null)
             connection.recycle();
         connection=null;
         if (stDelegate!=null)
             try{
>>>           stDelegate.close();
             } catch( Exception e ){}
         stDelegate=null;
         rsDelegate=null;
     }

     public void close()
         throws java.sql.SQLException
     {
         try{
             if (rsDelegate!=null)
                 rsDelegate.close();
             if (stDelegate!=null)
>>>         stDelegate.close();
         }
         finally
         {
             if (connection!=null)
                 connection.recycle();
             connection=null;
             stDelegate=null;
             rsDelegate=null;
         }
     }

so my question is if i am doing something wrong or if there is has a better
solution for that problem?


------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

Petr Jiricka wrote:
> I'm trying to use HttpServer.close() in Jetty 2.2.A1 and I'm getting this
exception in the log:
>
>       19990526 131658.357 GMT+02:00
>      
[ThreadedServer]com.mortbay.Util.ThreadedServer.run(ThreadedServer.java:274)
:CODE.WARN
>       gt;> Listen problem
>       gt;> java.net.SocketException: socket closed
>       gt;> at java.net.PlainSocketImpl.socketAccept(Native Method)
>       gt;> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
>       gt;> at java.net.ServerSocket.implAccept(ServerSocket.java:241)
>       gt;> at java.net.ServerSocket.accept(ServerSocket.java:224)
>       gt;> at com.mortbay.Util.ThreadedServer.run(ThreadedServer.java:261)
>       gt;> at java.lang.Thread.run(Thread.java:479)
>       gt;> --

I think this exception is due to the fact that the listener reports the
closure
of the socket caused by the close method - which is a bit brutal at the
moment.

We will look at a gentler version soon, but for now I think this
exception can
be ignored.

--
Greg Wilkins<gregw@...>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

Hi,
I'm trying to use HttpServer.close() in Jetty 2.2.A1 and I'm getting this
exception in the log:

19990526 131658.357 GMT+02:00
[ThreadedServer]com.mortbay.Util.ThreadedServer.run(ThreadedServer.java:274)
:CODE.WARN
   >> Listen problem
   >> java.net.SocketException: socket closed
   >>    at java.net.PlainSocketImpl.socketAccept(Native Method)
   >>    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
   >>    at java.net.ServerSocket.implAccept(ServerSocket.java:241)
   >>    at java.net.ServerSocket.accept(ServerSocket.java:224)
   >>    at com.mortbay.Util.ThreadedServer.run(ThreadedServer.java:261)
   >>    at java.lang.Thread.run(Thread.java:479)
   >> --

Am I doing something wrong or is that a bug ?

Thanks,
Petr Jiricka
NetBeans

------------------------------------------------------------------------
For the latest information about Jetty, please see http://www.mortbay.c

This is a list for users of the Jetty Open Source Java WWW server.

The list should be used for postings about the usage and development of the
Jetty server.

For the latest information about Jetty, please see http://www.mortbay.com


Group Manager: jetty-discuss-owner@egroups.com

To subscribe, send a message to jetty-discuss-subscribe@egroups.com or go to the
e-group's home page at http://www.egroups.com/list/jetty-discuss