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.

Reply via email to