We've built our own Elasticsearch Client that has niceties like; OAuth, the ability to swap Clusters for maintenance, Zookeeper integration, ease of configuration, retries, etc. Otherwise we'd have a lot of "wheel reinventing" going on. Plus, the Java Client is pretty nice, after all. ;-)
Thanks for all the input. (And kimchy, thanks for the brilliant product) Cheers, -- Chris On Mar 21, 2014, at 2:47 PM, Matt Weber <matt.we...@gmail.com> wrote: > If this is a concern, why not have your client's use the REST api so they > don't need to worry about matching their java version with the java version > of the search cluster? > > Thanks, > Matt Weber > > > > On Fri, Mar 21, 2014 at 12:07 PM, kimchy <kim...@gmail.com> wrote: > Not trivializing the bug at all, god knows I spend close to a week tracing it > down to a JVM backward incompatibility change, but this happened once over > the almost 5 years Elasticsearch existed. To introduce a workaround to > something that happened once, compared to potential bugs in the workaround > (Jackson is great, but what would happen if there was a bug in it for > example) is not a great solution. Obviously, if this happened more often, > then this is something we need to address. > > On Friday, March 21, 2014 7:12:02 PM UTC+1, Chris Berry wrote: > If it happened once, then by definition it will happen again. History repeats > itself. ;-) > > What exactly would you lose? > You are simply trading one rigid serialization scheme for another more > lenient one. > Yes, you would have to introduce something like Jackson's Object Mapper, but > that seems to be the defacto standard today and with your use of the Shade > Plugin it wouldn't really be a burden on the Client anyway. > > With all due respect, you may be trivializing the impact of this one time bug. > It is difficult, at best, to inform all the Clients of your Cluster; "Hey, if > you want to see what your Exceptions really are, then upgrade your JVM" > Especially in large SOA shops > > This just decouples the Client and Server deployments. > > Thanks much, > -- Chris > > On Mar 21, 2014, at 12:18 PM, kimchy <kim...@gmail.com> wrote: > >> I wonder why you are asking for this feature? If its because Java broke >> backward comp. on serialization of InetAddress that we use in our >> exceptions, then its a bug in Java serialization, hard for us to do >> something about it. >> >> You will loose a lot by trying to serialize exceptions using JSON, and we >> prefer not to introduce dependency on ObjectMapper in Jackson, or try and >> serialize exceptions using Jackson. >> >> I would be very careful in introducing this just because of a (one time bug) >> in Java. >> >> On Friday, March 21, 2014 5:18:38 PM UTC+1, Chris Berry wrote: >> Greetings, >> >> Let me say up-front, I am a huge fan and proponent of Elasticsearch. It is a >> beautiful tool. >> >> So, that said, it surprises me that Elasticsearch has such a pedestrian >> flaw, and serializes it's Exceptions using Java Serialization. >> In a big shop it is quite difficult (i.e. next to impossible) to keep all >> the ES Clients on the same exact JVM as Elasticsearch, and thus, it is not >> uncommon to get TransportSerializationExceptions instead of the actual >> underlying problem. >> I was really hoping this would be corrected in ES 1.0.X, but no such luck. >> (As far as I can tell...) >> >> It seems that this is pretty easily fixed? >> Just switch to a JSON representation of the basic Exception and gracefully >> (forwards-compatibly) attempt to re-hydrate the actual Exception class. >> You'd just have to drop an additional "header" in the stream that tells the >> code it is a JSON response and route to the right Handler it accordingly. If >> the header is missing, then do things the old way with Java Serialization?? >> >> Are there any plans to fix this? Or perhaps to entertain a Pull Request? >> It may seem just an annoyance, but it is actually pretty bad, in that it >> keeps Clients from seeing their real issues. Especially in shops where it is >> difficult to see the Production logs of Elasticsearch itself. >> >> Thanks much, >> -- Chris >> >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "elasticsearch" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elasticsearch/7bpam7mWjY8/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> elasticsearc...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/6ae5f173-a2b4-435c-8e5d-a43d377e2fb0%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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/891337f7-230f-4ce2-a2b4-57749f095748%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "elasticsearch" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elasticsearch/7bpam7mWjY8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elasticsearch+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAJ3KEoDB%2BVqpKvc3BPbnX2COxpwMi35GmON1bBKD74u9APJ2HQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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/BBE77D8F-DCCD-491B-A610-B4C568F2224A%40gmail.com. For more options, visit https://groups.google.com/d/optout.