Other than because everyone keeps asking for support for their favorite
mechanism. ;-)
BTW, I entered a patch for ZOOKEEPER-268 just now. Turns out that the
jute code was catching the NPE and outputting it to the screen, then
eating it. So the "infinite" loop really is just each packet is bein
protocol buffers are nice... the variable int stuff is cool.
Though is the protocol very complicated? Why not write a custom hand
written Externalizable format?
These frameworks are often more trouble than they're worth for small
protocols.
Kevin
On Wed, Jan 7, 2009 at 2:46 PM, Patrick Hunt
Whatever we do the changes should support having more than one
marshaling format/version co-exist. Both for b/w compatibility as well
as enabling different serialization mechanisms (jute or pbuffer or
thrift or etch, etc...)
Patrick
Mahadev Konar wrote:
The version of Jute we use is really a
The version of Jute we use is really an ancient version of recordio
ser/deser library in hadoop. We do want to move to some
better(versioned/fast/well accepted) ser/deser library.
mahadev
On 1/7/09 12:08 PM, "Kevin Burton" wrote:
> Ah... you think it was because it was empty? Interesting. I
Ah... you think it was because it was empty? Interesting. I will have to
play with Jute a bit.
Kevin
On Wed, Jan 7, 2009 at 10:07 AM, Patrick Hunt wrote:
> Thanks for the report, entered as:
> https://issues.apache.org/jira/browse/ZOOKEEPER-268
>
> For the time being you can work around th
Thanks for the report, entered as:
https://issues.apache.org/jira/browse/ZOOKEEPER-268
For the time being you can work around this by setting the threshold to
INFO for that class (in log4j.properties). Either that or just set the
data to a non-empty value for the znode.
Patrick
Kevin Burton
Creating this node with this ACL:
Created /foo
setAcl /foo world:anyone:w
Causes the exception included below.
It's an infinite loop so it's just called over and over again filling my
console.
I'm just doing an exists( path, true ); ... setting a watch still causes the
problem.
java.lang.Null