We have a master-slave-architecture which delegates an index update to the master. When the slave tries to inform the master via JMSBackendQueueProcessor the object including a NumericField gets serialized. A NotSerializableException occurs on a NumericTokenStream. The NumericField extends AbstractField, which implements Serializable, but it cannot be serialized because it stores the precisionStep in the underlying NumericTokenStream, which is not serializable.

Hi,

thanks for that. Could you create a Jira issue - http://opensource.atlassian.com/project ... se/HSEARCH - and maybe even attach a testcase?
That would be much appreciated.

--Hardy

I opened an Issue:
http://opensource.atlassian.com/project ... SEARCH-681

Thanks :)

Is there any update on this issue?

It seems that because of this issue, master/slave replication is totally broken if you use NumericFields.

Is there any workaround?

Also, I'm curious to know what the plan is for Hibernate Search with regard to the fact that Lucene has removed all support for serialization in Lucene 4 (see: https://issues.apache.org/jira/browse/LUCENE-2908 ) and doesn't plan on fixing it in the 3.x branch (see: https://issues.apache.org/jira/browse/LUCENE-2707)

Since the master/slave architecture works by serializing Lucene Documents over the wire, it would seem that something needs to be changed.

Thanks,
Marc

Hi Marc,
yes definitely something needs to be changed. Currently, you have to avoid either master/slave backend or NumericFields.
You could try the Infinispan directory, which is a better fit in many other ways, but under heavy write load on multiple nodes this also needs a master/slave setup (if you only need failover and write to one at the same time you won't need it) to prevent long waits on locking (and Lucene's implementation of a "wait on" lock is very bad for this use case as there's no notification, only polling).

We're going to abstract the Document from the wire, if you really need a workaround now you can write your own backend and plug it in, you only have to implement
org.hibernate.search.backend.BackendQueueProcessorFactory
(you could have a look into org.hibernate.search.backend.impl.blackhole.BlackHoleBackendQueueProcessorFactory for a skeleton implementation)
and write some code which reads the Document, "serializes it" in some custom way, and then on the JMS client you deserialize it again before feeding it in Search again.

a patch would be appreciated.