• When waiting for a new request to be received on a connection
  • When reading the headers and content of a request
  • When writing the headers and content of a response
    • Jetty interprets this value as the maximum time between some progress being made on the connection. So if a single byte is read or written, then the timeout (if implemented by jetty) is reset. However, in many instances, the reading/writing is delegated to the JVM, and the semantic is more strictly enforced as the maximum time a single read/write operation can take. Note, that as Jetty supports writes of memory mapped file buffers, then a write may take many 10s of seconds for large content written to a slow device.

    Previously, Jetty supported separate idle timeouts and IO operation timeouts, however the expense of changing the value of soTimeout was significant, so these timeouts were merged. With the advent of NIO, it may be possible to again differentiate these values (if there is demand). ]]>

  • When waiting for a new request to be received on a connection
  • When reading the headers and content of a request
  • When writing the headers and content of a response
    • Jetty interprets this value as the maximum time between some progress being made on the connection. So if a single byte is read or written, then the timeout (if implemented by jetty) is reset. However, in many instances, the reading/writing is delegated to the JVM, and the semantic is more strictly enforced as the maximum time a single read/write operation can take. Note, that as Jetty supports writes of memory mapped file buffers, then a write may take many 10s of seconds for large content written to a slow device.

    Previously, Jetty supported separate idle timeouts and IO operation timeouts, however the expense of changing the value of soTimeout was significant, so these timeouts were merged. With the advent of NIO, it may be possible to again differentiate these values (if there is demand). ]]>

  • When waiting for a new request to be received on a connection
  • When reading the headers and content of a request
  • When writing the headers and content of a response
    • Jetty interprets this value as the maximum time between some progress being made on the connection. So if a single byte is read or written, then the timeout (if implemented by jetty) is reset. However, in many instances, the reading/writing is delegated to the JVM, and the semantic is more strictly enforced as the maximum time a single read/write operation can take. Note, that as Jetty supports writes of memory mapped file buffers, then a write may take many 10s of seconds for large content written to a slow device.

    Previously, Jetty supported separate idle timeouts and IO operation timeouts, however the expense of changing the value of soTimeout was significant, so these timeouts were merged. With the advent of NIO, it may be possible to again differentiate these values (if there is demand). ]]> Server classes/packages are classes used to implement the server and are hidden from the context. If the context needs to load these classes, it must have its own copy of them in WEB-INF/lib or WEB-INF/classes. A class pattern is a string of one of the forms:

    org.package.Classname
    Match a specific class
    org.package.
    Match a specific package hierarchy
    -org.package.Classname
    Exclude a specific class
    -org.package.
    Exclude a specific package hierarchy
    ]]>         System classes/packages are classes provided by the JVM and that cannot be replaced by classes of the same name from WEB-INF, regardless of the value of {@link #setParentLoaderPriority(boolean)}. A class pattern is a string of one of the forms:
    org.package.Classname
    Match a specific class
    org.package.
    Match a specific package hierarchy
    -org.package.Classname
    Exclude a specific class
    -org.package.
    Exclude a specific package hierarchy
    ]]>         A. Try to use an explicit directory specifically for this webapp:

    1. Iff an explicit directory is set for this webapp, use it. Do NOT set delete on exit.
    2. Iff javax.servlet.context.tempdir context attribute is set for this webapp && exists && writeable, then use it. Do NOT set delete on exit.

    B. Create a directory based on global settings. The new directory will be called "Jetty_"+host+"_"+port+"__"+context+"_"+virtualhost Work out where to create this directory:

    1. Iff $(jetty.home)/work exists create the directory there. Do NOT set delete on exit. Do NOT delete contents if dir already exists.
    2. Iff WEB-INF/work exists create the directory there. Do NOT set delete on exit. Do NOT delete contents if dir already exists.
    3. Else create dir in $(java.io.tmpdir). Set delete on exit. Delete contents if dir already exists.
    ]]>