WARN net.spy.memcached.transcoders.SerializingTranscoder: Caught IOException decoding bytes of data


I started to get a weird exception
java.io.InvalidClassException: package.com.something.Some_Hibernate_Table; no valid constructor
at java.io.ObjectStreamClass.checkDeserialize(ObjectStreamClass.java:730)
.
.
.
Some_Hibernate_Table

The stack trace was very weird, it hinted at a launch stack, and a exception from a table other than what I was sending data to. Infact after doing some debugging, step by step, this exception happened on a get on a SomeOther_Hibernate_Table.

Crazy root cause.. 🙂
Old code
List tableRow = null ;
if (isCacheable) {
tableRow value = cache.get(key) ;
return tableRow
}
String rowQuery = “Select * from ” + tableName + ” where ” + column + “=” + “\”” + key + “\””;
Query rowResult = currentSession().createSQLQuery(rowQuery);
tableRow = rowResult.list();

The cache returns a Object, but hibernate.createSQLQuery returns a List. So to keep things clean, the fix below.
Object value = cache.get(key) ;
if (isCacheable) {
if (value != null) {
tableRow = new ArrayList() ;
tableRow.add(value);
return tableRow;
}
}
String rowQuery = “Select * from ” + tableName + ” where ” + column + “=” + “\”” + key + “\””;
Query rowResult = currentSession().createSQLQuery(rowQuery);
tableRow = rowResult.list();

Advertisements

One thought on “WARN net.spy.memcached.transcoders.SerializingTranscoder: Caught IOException decoding bytes of data

  1. I thought the above change would fix it, but to be honest it did not. I was missing a basic serialization concept. This link http://www.jguru.com/faq/view.jsp?EID=34802 helped me understand.

    When you serialize an object, the serialization mechanism works by chaining up the inheritence hierarchy, saving the sate of each Serializable superclass in turn. When serialization reaches the first non-serializable superclass, the serialization stops.

    When deserializing, the state of this first non-serializable superclass is restored not from the stream, but by invoking that class’ no-argument constructor. If the no-argument constructor is not adequate for your purposes, you must customize the serialization of your subclass with writeObject() and readObject() in order to write out and restore any information from the non-serializable superclass that you find necessary.

    I was trying to add records to memcached from hibernate classes that extended from common functionality (over do of design patterns here:)). I than realized that hibernate pojo’s need to be just that, pojo’s.

    I isolated my hibernate pojo’s from my memcached caching/retrieval logic and WOW FINALLY YIPPPPPPY NO MORE CRAZY EXCEPTIONS… ok.. got a bit excited there.

    Hope this helped.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s