Park or deadlock thread on callSendError.

Hello.

I ran into the problem of executing queries (if so important, for asynchronous queries).

Here's the dump:
```

"DefaultQuartzScheduler_Worker-2" J9VMThread:0x0000000005789900, j9thread_t:0x00007F51F80A39B0, java/lang/Thread:0x00000005963FAC48, state:P, prio=5
(java/lang/Thread getId:0xEA, isDaemon:false)
(native thread ID:0x1AB7, native priority:0x5, native policy:UNKNOWN, vmstate:P, vm thread flags:0x00020001)
(native stack address range from:0x00007F51C6FAB000, to:0x00007F51C6FEC000, size:0x41000)
CPU usage total: 19.877874305 secs, current category="Application"
Parked on: jersey/repackaged/com/google/common/util/concurrent/AbstractFuture$Sync@0x0000000598B21798 Owned by:
Heap bytes allocated since last GC cycle=0 (0x0)
Java callstack:
at sun/misc/Unsafe.park(Native Method)
at java/util/concurrent/locks/LockSupport.park(LockSupport.java:198(Compiled Code))
at java/util/concurrent/locks/AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:846(Compiled Code))
at java/util/concurrent/locks/AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1006)
at java/util/concurrent/locks/AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1315(Compiled Code))
at jersey/repackaged/com/google/common/util/concurrent/AbstractFuture$Sync.get(AbstractFuture.java:285(Compiled Code))
at jersey/repackaged/com/google/common/util/concurrent/AbstractFuture.get(AbstractFuture.java:116(Compiled Code))
at org/glassfish/jersey/servlet/internal/ResponseWriter.getResponseContext(ResponseWriter.java:299(Compiled Code))
at org/glassfish/jersey/servlet/internal/ResponseWriter.callSendError(ResponseWriter.java:215(Compiled Code))
at org/glassfish/jersey/servlet/internal/ResponseWriter.commit(ResponseWriter.java:194(Compiled Code))
at org/glassfish/jersey/server/ContainerResponse.close(ContainerResponse.java:413(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$Responder.writeResponse(ServerRuntime.java:784(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$Responder.processResponse(ServerRuntime.java:444(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$Responder.process(ServerRuntime.java:434(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$AsyncResponder$3.run(ServerRuntime.java:934(Compiled Code))
at org/glassfish/jersey/internal/Errors$1.call(Errors.java:271(Compiled Code))
at org/glassfish/jersey/internal/Errors$1.call(Errors.java:267(Compiled Code))
at org/glassfish/jersey/internal/Errors.process(Errors.java:315(Compiled Code))
at org/glassfish/jersey/internal/Errors.process(Errors.java:297(Compiled Code))
at org/glassfish/jersey/internal/Errors.process(Errors.java:267(Compiled Code))
at org/glassfish/jersey/process/internal/RequestScope.runInScope(RequestScope.java:317(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$AsyncResponder.resume(ServerRuntime.java:966(Compiled Code))
at org/glassfish/jersey/server/ServerRuntime$AsyncResponder.resume(ServerRuntime.java:922(Compiled Code))
at ru/denis/job/impl/CheckEventJob.execute(CheckEventJob.java:69(Compiled Code))
(entered lock: java/lang/Object@0x0000000598B1F0C8, entry count: 1)
at org/quartz/core/JobRunShell.run(JobRunShell.java:202(Compiled Code))
at org/quartz/simpl/SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
(entered lock: java/lang/Object@0x00000005963FACF8, entry count: 1)
Native callstack:
(0x00007F5276974A72 [libj9prt27.so+0x16a72])
(0x00007F5276983B45 [libj9prt27.so+0x25b45])
(0x00007F52769745EC [libj9prt27.so+0x165ec])
(0x00007F52769746EE [libj9prt27.so+0x166ee])
(0x00007F5276983B45 [libj9prt27.so+0x25b45])
(0x00007F52769741CF [libj9prt27.so+0x161cf])
(0x00007F527696D8AE [libj9prt27.so+0xf8ae])
(0x0000003591C0F790 [libpthread.so.0+0xf790])
pthread_cond_wait+0xca (0x0000003591C0B63A [libpthread.so.0+0xb63a])
j9thread_park+0x9b (0x00007F5276DBBDAB [libj9thr27.so+0x5dab])
(0x00007F5277074F08 [libj9vm27.so+0xaaf08])
(0x00007F524EE33B98 [+0x0])

```

Repeat the problem is not possible, because the primary reason is unknown.

Load testing did not detect issue. It's randomly occur, but very often.

But here are the cases I did for the repetition of the incident:
1) I did a slow data retrieval, but then the thread on the dump hung on the response writer.
2) I forcibly broke the connection between the request of the browser and the application (I use nginx for proxy, without buffering).

But in none of the cases I could not get the sendError method with response.isCommitted () = false.

Tell me, please, how it is possible to simulate a request that will return response.isCommitted () = false.