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)





Reply via email to