JAX-WS RI is capable of running a large number of request/response concurrently by using a relatively small number of threads. This is made possible by utilizing a {@link Fiber} — a user-level thread that gets created for each request/responseprocessing.
A fiber remembers where in the pipeline the processing is at, what needs to be executed on the way out (when processing response), and other additional information specific to the execution of a particular request/response.
Fiber can be {@link NextAction#suspend() suspended} by a {@link Tube}. When a fiber is suspended, it will be kept on the side until it is {@link #resume(Packet) resumed}. This allows threads to go execute other runnable fibers, allowing efficient utilization of smaller number of threads.
{@link FiberContextSwitchInterceptor} allows {@link Tube}s and {@link Adapter}s to perform additional processing every time a thread starts running a fiber and stops running it.
Just like thread, a fiber has a context class loader (CCL.) A fiber's CCL becomes the thread's CCL when it's executing the fiber. The original CCL of the thread will be restored when the thread leaves the fiber execution.
Because {@link Fiber} doesn't keep much in the call stack, and instead use{@link #conts} to store the continuation, debugging fiber related activitiescould be harder.
Setting the {@link #LOGGER} for FINE would give you basic start/stop/resume/suspendlevel logging. Using FINER would cause more detailed logging, which includes what tubes are executed in what order and how they behaved.
When you debug the server side, consider setting {@link Fiber#serializeExecution}to true, so that execution of fibers are serialized. Debugging a server with more than one running threads is very tricky, and this switch will prevent that. This can be also enabled by setting the system property on. See the source code. @author Kohsuke Kawaguchi @author Jitendra Kotamraju
|
|
|
|
|
|
|
|
|
|
|
|