java.lang.NullPointerException at org.vertx.java.core.http.impl.ClientConnection.handleResponseChunk

Trevor S

unread,

Jun 12, 2014, 9:46:38 AM6/12/14

to ve...@googlegroups.com

Hi, i'm getting this error when using an http client from within vertx when it is processing http responses. It might mean i will have to try another http client for a library i am writing! :(

09:11:15.005 [vert.x-worker-thread-17] ERROR n.g.c.vertx.AppService-1020249413 - Exception in Groovy verticle

java.lang.NullPointerException: null

at org.vertx.java.core.http.impl.ClientConnection.handleResponseChunk(ClientConnection.java:306) ~[vertx-core-2.1.jar:na]

at org.vertx.java.core.http.impl.DefaultHttpClient$ClientHandler.doMessageReceived(DefaultHttpClient.java:802) [vertx-core-2.1.jar:na]

at org.vertx.java.core.http.impl.DefaultHttpClient$ClientHandler.doMessageReceived(DefaultHttpClient.java:775) [vertx-core-2.1.jar:na]

at org.vertx.java.core.http.impl.VertxHttpHandler$1.run(VertxHttpHandler.java:71) [vertx-core-2.1.jar:na]

at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175) [vertx-core-2.1.jar:na]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_45]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_45]

at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]

i do not get this when running from a standalone unit test, but i do from inside a running vertx app (i'm checking tomcat shortly) Either way, i initialize the client as Vertx.newVertx().createHttpClient. But when the same client code is run inside a vertx worker verticle, i don't get http responses.

also, when i run vertx:runMod in debugger mode, and set breakpoint at ClientConnection.java:306, it does sometime work and process the response. (!!??!)

note the vertx exception below and the attached debugger screen shot of nullpointers in netty DefaultHttyHeaders.getKey(). not sure if that is the cause or just coincidence.

my code is doing this (approx)...

def method() {

def latch - new CountDownLatch(1)

client.post(url) { response ->

println "Response has status $response.status"

if (response.status == 200) {

// we get here

response.bodyHandler { buffer ->

// we never get here

rawResponse = buffer.toString()

latch.countdown()

}.end(content)

latch.await(10, TimeUnit.SECONDS)

return rawResponse

}

any help/pointers would be appreciated.

Thanks,

Trevor

netty.png

Trevor S

unread,

Jun 12, 2014, 8:28:15 PM6/12/14

to ve...@googlegroups.com

i've simulated this now again just using vertx and also got it to work by running the http client in a non-worker verticle.

In summary, my conclusion is that you cannot use HttpClient in a worker verticle..because it seems to want to run on the event loop(?)

Tim can you please confirm this?

Tim Fox

unread,

Jun 13, 2014, 3:03:42 AM6/13/14

to ve...@googlegroups.com

I think it's this issue: https://github.com/eclipse/vert.x/pull/826

It will manifest when embedding or on a worker verticle.

The fix is pretty trivial - it's already fixed in the 3.0 codebase, I guess I should fix it in the 2.1 branch too...

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Trevor S

unread,

Jun 13, 2014, 7:51:12 PM6/13/14

to ve...@googlegroups.com

oh, if you could merge that into 2.1 i would be exceedingly grateful ... we go to prod in 3 weeks! i'll build from src. :)

Trevor S

unread,

Jun 13, 2014, 7:58:46 PM6/13/14

to ve...@googlegroups.com

btw, if i make the worker verticle NOT multithreaded, the issue is relaxed a bit. (it works after the first attempt (which fails to actually post), but i am only testing sequentially at the moment.)

Norman Maurer

unread,

Jun 14, 2014, 3:04:00 AM6/14/14

to ve...@googlegroups.com

As far as I can tell Tim merged the fix into master yesterday

Tim Fox

unread,

Jun 14, 2014, 3:37:31 AM6/14/14

to ve...@googlegroups.com

It's fixed in master now. Can you try it out?

We'll do a 2.1.1 release in the next couple of weeks.

Trevor S

unread,

Jun 14, 2014, 12:53:19 PM6/14/14

to ve...@googlegroups.com

i uploaded a sample project that shows the issue here. 2.1.1-snapshot didnt seem to fix,

https://github.com/samart/httpclient

if you do a mvn runMod and hit http://localhost:9903/api/doPost from your browser u will see.

then in Bootstrap, change the HttpClientVerticle to multithreaded=false. it then works, but sometimes gets 'stuck' - you'll see your browser waiting. (note, i dont think i actually need a multthreaded verticle, but there is this periodic sticking issue with the single threaded one)

This example is written in the spirit of how my app is constructed. the client api is to be used standalone as well. (note, i'm also using SSL with my client (which works great btw), but i was able to recreate the issue with this simple example)

Tim Fox

unread,

Jun 14, 2014, 1:02:58 PM6/14/14

to ve...@googlegroups.com

Can I ask why you are using a multi-threaded worker verticle?

For most apps standard verticles will be the norm, unless you have to call a blocking API, in which case you can encapsulate the blocking logic in a worker verticle, but even then it's unlikely to be multi-threaded.

Trevor S

unread,

Jun 14, 2014, 1:47:30 PM6/14/14

to ve...@googlegroups.com

Yeah, i don't think i need to use a multithreaded verticle...ultimately I'm starting N verticle instances and they share a spring app context...so That's fine. It's just that it's been working just fine for a while now, until adding this http call to an external service. I didn't expect an issue..but here we are.

But the example still shows a bit of sticking with a single threaded verticle and I would be interested in knowing how to resolve that. If we solve this stickiness (non responses) on some post responses with a single threaded verticle I am fine.

Trevor S

unread,

Jun 14, 2014, 1:51:15 PM6/14/14

to ve...@googlegroups.com

Having said that, should http client work in a multithreaded worker verticle? It's not clear to me, and If not, that would be good to document for the next guy? What does that imply for using http client posts in multithreaded tomcat for example?

Thanks for help and great work with vertx, much appreciated!!!

Tim Fox

unread,

Jun 14, 2014, 3:02:31 PM6/14/14

to ve...@googlegroups.com

Well it should work ;) Can you open a BZ?

On 14/06/14 18:51, Trevor S wrote:
> Having said that, should http client work in a multithreaded worker verticle? It's not clear to me, and If not, that would be good to document for the next guy? What does that imply for using http client posts in multithreaded tomcat for example?

Can you explain a bit about where Tomcat comes into this? I'm not
familiar with your use case.

Trevor S

unread,

Jun 14, 2014, 3:59:32 PM6/14/14

to ve...@googlegroups.com

Thanks, i created a BZ https://bugs.eclipse.org/bugs/show_bug.cgi?id=437457

2 more notes

1) when using as single threaded and left for a while with no activity, initial subsequent requests nullpointer, but then the client seems to 'wake' up and start processing after the second or third request.

INFO] ====== SUCCESS - we got the response in the client =======

[INFO] Business logic is executing...

[INFO] External service is responding to post request with {"response":{"status":"Success","message":"this is the external service post response"}}

[INFO] GOT POST RESPONSE WITH STATUS 200.

[INFO] ====== SUCCESS - we got the response in the client =======

[INFO] Business logic is executing...

[INFO] External service is responding to post request with {"response":{"status":"Success","message":"this is the external service post response"}}

[INFO] GOT POST RESPONSE WITH STATUS 200.

Jun 14, 2014 3:21:23 PM org.vertx.java.core.logging.impl.JULLogDelegate error

SEVERE: Exception in Groovy verticle

java.lang.NullPointerException

at org.vertx.java.core.http.impl.ServerConnection.handleChunk(ServerConnection.java:200)

at org.vertx.java.core.http.impl.ServerConnection.processMessage(ServerConnection.java:307)

at org.vertx.java.core.http.impl.ServerConnection.handleMessage(ServerConnection.java:94)

at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:695)

at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:585)

at org.vertx.java.core.http.impl.VertxHttpHandler$1.run(VertxHttpHandler.java:71)

at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:722)