I'm done with the serialization protocol. At least, it's in a good shape and should be integrated with trunk It uses Avro and is now integrated with both JGroups and JMS backends. I've abstracted Avro from our serialization logic so we can write alternative prototypes. I'd be interested to see a Protocol Buffer alternative for example. If anyone is interested, check out SerializationProvider and it's inplementation AvroSerializationProvider Not everything is polished, I've created a list of follow up issues to be fixed before 4.0. https://hibernate.onjira.com/browse/HSEARCH-757 These a good candidates for community contribution. I have one minor question Should hibernate.search.jms.indexNameProperty that be part of the protocol or left separate like today? I'll send a pull request in the next few minutes Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi Emmanuel, 2011/8/6 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > I forgot to say that > > Our avro serializer is slower (1.6) than Java serialization esp when the VM is not warm (small loop value like = 1000 > In evens up on longer loops like 100000 > > Our avro serializer is slower (2.5) than Java serialization esp when the VM is not warm (small loop value like = 1000 > In evens up or beats the Java serialization on longer loops like 100000 What is the meaning of the number in parenthesis (the number which makes the two statements different) ?

> However, Avro's message is half the size and there are some room for improvement. that sounds pretty good and well suited for our purpose.

>> >> I have one minor question >> Should hibernate.search.jms.indexNameProperty that be part of the protocol or left separate like today? You likely noticed I had it included in the JGroups backend, since it has no such properties. I've no strong opinions about it, only thing I can think of is that having it in the protocol would likely be better since it means it will be included in what we consider "binary format" and test for in backwards compatibility; for example I think it should be "optional": defined only if the receiving side handles more than a single index.

>> I'll send a pull request in the next few minutes I'll review it as soon as you do.