Swati, Well, I tend not to use the built-in Jackson parser anymore. The only advantage I've seen to stream parsing is that I can dynamically adapt to different objects in my own code. But I can't release the code since it's owned by my employer. And for most tasks these days, I use the Jackson jar files and the data binding model. By the way, here are the only additional JAR files that I use in my Elasticsearch-based tools that also include Elasticsearch jars:
For the full Jackson support. There are later versions but these work for now until the rest of the company moves to Java 8: jackson-annotations-2.2.3.jar jackson-core-2.2.3.jar jackson-databind-2.2.3.jar This gives me the full Netty server (got tired of looking for it buried inside ES, and found this to be very simple and easy to use). Again, there are later versions but this one works well enough: netty-3.5.8.Final.jar And this is the magic that brings Netty to life. My front end simply publishes each incoming Netty MessageEvent to the LMAX Disruptor ring buffer. Then I can predefine a fixed number of background WorkHandler threads to consume the MessageEvent objects, handling each one and responding back to its client. No matter how much load is slammed into the front end, the number of Netty threads stays small since they only publish and they're done. And so, the total thread count stays small even when intense bursts of clients slam the server: disruptor-3.2.0.jar I hope this helps. I'd love to publish more details but this is about all I can do for now. Brian -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/773a4516-89c1-4e21-bd65-e5e7bf48c7e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
