InputStreamContentProvider wrapping exceptions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

InputStreamContentProvider wrapping exceptions

John Gardiner Myers
InputStreamContentProviderIterator.next() wraps failures in a
NoSuchElementException, presumably because it can't throw an
IOException. Unfortunately, this tends to obscure the real failure.

Would it make sense for ContentCallback.process() to unwrap the
NoSuchElementException when it has a cause?

java.util.NoSuchElementException: null
         at
org.eclipse.jetty.client.util.InputStreamContentProvider$InputStreamContentProviderIterator.next(InputStreamContentProvider.java:231)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.util.InputStreamContentProvider$InputStreamContentProviderIterator.next(InputStreamContentProvider.java:166)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpContent.advance(HttpContent.java:139)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpSender$ContentCallback.process(HttpSender.java:755)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:246)
~[jetty-util-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:208)
~[jetty-util-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpSender$CommitCallback.process(HttpSender.java:694)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpSender$CommitCallback.succeeded(HttpSender.java:644)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpSenderOverHTTP$ByteBufferRecyclerCallback.succeeded(HttpSenderOverHTTP.java:238)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:321)
~[jetty-io-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:129)
~[jetty-io-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpSenderOverHTTP.sendHeaders(HttpSenderOverHTTP.java:108)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpSender.send(HttpSender.java:183)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpChannelOverHTTP.send(HttpChannelOverHTTP.java:64)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpConnectionOverHTTP$Delegate.send(HttpConnectionOverHTTP.java:188)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpConnectionOverHTTP.send(HttpConnectionOverHTTP.java:75)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpDestinationOverHTTP.send(HttpDestinationOverHTTP.java:36)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.http.HttpDestinationOverHTTP.send(HttpDestinationOverHTTP.java:26)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.PoolingHttpDestination.process(PoolingHttpDestination.java:138)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.PoolingHttpDestination.send(PoolingHttpDestination.java:73)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:187)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpClient.send(HttpClient.java:518)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:682)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:675)
~[jetty-client-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
com.proofpoint.http.client.jetty.JettyHttpClient.execute(JettyHttpClient.java:214)
~[http-client-1.15.jar:na]
         at
com.proofpoint.http.client.balancing.BalancingHttpClient.execute(BalancingHttpClient.java:96)
~[http-client-1.15.jar:na]
[...elided...]
Caused by: org.eclipse.jetty.io.EofException: Early EOF
         at
org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:505)
~[jetty-server-9.2.9.v20150224.jar:9.2.9.v20150224]
         at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:124)
~[jetty-server-9.2.9.v20150224.jar:9.2.9.v20150224]
         at
org.glassfish.jersey.message.internal.EntityInputStream.read(EntityInputStream.java:101)
~[jersey-common-2.13.jar:na]
         at
org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream.read(ReaderInterceptorExecutor.java:300)
~[jersey-common-2.13.jar:na]
         at java.io.FilterInputStream.read(FilterInputStream.java:133)
~[na:1.7.0_75]
[...elided...]

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: InputStreamContentProvider wrapping exceptions

John Gardiner Myers
On 3/26/2015 3:03 PM, John Gardiner Myers wrote:
> InputStreamContentProviderIterator.next() wraps failures in a
> NoSuchElementException, presumably because it can't throw an
> IOException. Unfortunately, this tends to obscure the real failure.
>
> Would it make sense for ContentCallback.process() to unwrap the
> NoSuchElementException when it has a cause?

Or perhaps the problem is that Jetty let the exception propagate out of
HttpRequest.send() instead of swallowing it somewhere. When it
propagates out of HttpRequest.send(), the caller is likely to act on (or
propagate) that an not even look at the Listener.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: InputStreamContentProvider wrapping exceptions

Simone Bordet-2
Hi,

On Thu, Mar 26, 2015 at 11:19 PM, John Gardiner Myers
<[hidden email]> wrote:

> On 3/26/2015 3:03 PM, John Gardiner Myers wrote:
>>
>> InputStreamContentProviderIterator.next() wraps failures in a
>> NoSuchElementException, presumably because it can't throw an IOException.
>> Unfortunately, this tends to obscure the real failure.
>>
>> Would it make sense for ContentCallback.process() to unwrap the
>> NoSuchElementException when it has a cause?
>
>
> Or perhaps the problem is that Jetty let the exception propagate out of
> HttpRequest.send() instead of swallowing it somewhere. When it propagates
> out of HttpRequest.send(), the caller is likely to act on (or propagate)
> that an not even look at the Listener.

Jetty client does swallow the exception and fails the callback,
resulting in the complete event being triggered, see
HttpSender.send[Headers|Content]() catch-all block.
The unwrapped exception actually tells me that it happened while you
were reading the request content of a request to a server, so you're
actually using Jetty's HttpClient as a kind of proxy.
I would not have known that by just reading the unwrapped exception,
so seems even useful to me...

--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: InputStreamContentProvider wrapping exceptions

John Gardiner Myers
On 3/30/2015 6:50 AM, Simone Bordet wrote:
> Jetty client does swallow the exception and fails the callback,
> resulting in the complete event being triggered, see
> HttpSender.send[Headers|Content]() catch-all block. The unwrapped
> exception actually tells me that it happened while you were reading
> the request content of a request to a server, so you're actually using
> Jetty's HttpClient as a kind of proxy. I would not have known that by
> just reading the unwrapped exception, so seems even useful to me...
The class of the wrapper is confusing, if not actively misleading. The
failure was not a programming error, it was the failure of a
ContentProvider to produce content. If the wrapper were of a class, say,
ContentProviderExecutionException then that would be a lot more informative.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users