It seems that Jetty tries to get back a thread from the active thread pool (perhaps after MaxIdleTime) by issuing the Thread#interrupt. It closes active NIO channels and breaks Berkley DB JE (see their SR #10463).
a) Jetty must not intterrupt a thread that is still doing something. If user wants Jetty to do so, he should explicitly ask for it. Issuing Thread#interrupt may break user application running under Jetty in unpredictable ways.
b) If my assumption about MaxIdleTime is right, it is incorrect to apply idle time counter to the thread which is not, in fact, idle. The time Jetty waits for active server threads to finish must be configured separately from the time Jetty waits for client user-agents. As i've said in
JETTY-63 bug report, Jetty must either turn off all timeouts while a server thread is active, or use a separate timeout value for both TCP/IP SO_TIMEOUT and Jetty's internal expiration timeout.