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 <javascript:>> > 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 <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/6ae5f173-a2b4-435c-8e5d-a43d377e2fb0%40googlegroups.com<https://groups.google.com/d/msgid/elasticsearch/6ae5f173-a2b4-435c-8e5d-a43d377e2fb0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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.
