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 being
output to the log, causing this NPE to be printed to the console every
time (looks like get data response). Anyway, I've fixed the underlying
problem that was causing the NPE and submitted as a patch along with a
test that verifies. Thanks for the report.
Patrick
Kevin Burton wrote:
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 <ph...@apache.org> wrote:
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 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" <bur...@spinn3r.com> wrote:
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 <ph...@apache.org> wrote:
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 wrote:
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.NullPointerException
at org.apache.jute.Utils.toCSVBuffer(Utils.java:234)
at
org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101)
at
org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586)
at
org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852)
java.lang.NullPointerException
at org.apache.jute.Utils.toCSVBuffer(Utils.java:234)
at
org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101)
at
org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586)
at
org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852)
