[infinispan-dev] First version of JBoss Marshalling based Marshaller

[David M. Lloyd]

Remember that if there's a problem with data size, you can always use the 
Serial implementation (this implementation implements the Java 
Serialization spec so there won't be a size difference from what was there 
before; my crappy benchmarks show that even Serial is roughly 2x faster 
than Java Serialization for the small data sets that I measured with).  But 
the River implementation should be the same size or smaller (since many 
common classes, like primitive wrappers, are collapsed down to a single 
byte).  Since you're using ClassTables it should be much smaller.

Of course if you really miss JBoss Serialization, Ron has a JBoss 
Serialization implementation that will probably go in to 1.2.0.GA. :-)

- DML

On 04/11/2009 02:16 AM, Bela Ban wrote:
> I suggest you also take a look at performance and the size of te 
> marshalled data, compared to the current marshalling code.
> 
> I recall we had a bad experience with JBoss Serialization, which blew up 
> our data
> 
> Galder Zamarreno wrote:
>> Hi,
>>
>> Re: https://jira.jboss.org/jira/browse/ISPN-44
>>
>> I've attached a patch to the JIRA containing a 1st implementation of a 
>> JBoss Marshalling based marshalling layer for Infinispan. A few notes:
>>
>> - JBMAR based marshalling is optional for the moment. To enable it, 
>> configure the marshaller to be 
>> org.infinispan.marshall.jboss.JBossMarshaller.
>>
>> - I created a new profile that runs the testsuite with this 
>> marshaller. To run, just do: mvn -Ptest-jbossmarshaller test.
>>
>> - I've run the testsuite for core and there're no regressions with new 
>> marshaller. I also wanted to test jdbc but the testsuite seems to need 
>> a bit of tidying up or I need to preconfigure something (Tests run: 
>> 177, Failures: 4, Errors: 0, Skipped: 164, Time elapsed: 0.631 sec <<< 
>> FAILURE!). Regardless, jdbc uses a dummy marshaller so would be 
>> pointless for the moment.
>>
>> - Different type marshalling has been implemented using 
>> org.jboss.marshalling.Externalizer implementations mapped from 
>> HorizonMarshaller class. JBMAR does support Externalizable classes but 
>> I figured it out later and wanted to touch as less of existing code as 
>> possible. So, for Beta1, some of Externalizer implementations (except 
>> JDK classes) will probably go in favour of Externalizable 
>> implementations.
>>
>> - StateTransferManagerImpl uses marshaller in a different way to the 
>> rest. It first opens an ObjectOutput and then makes multiple calls to 
>> stream stuff. StateTransferManagerImpl was hardcoded to use OOS and 
>> OIS so I had to add org.infinispan.marshall.Marshaller that would 
>> start/finish these OO/OI implementations. This is to enable 
>> JBossMarshaller to provide OO/OI implementations coming from JBMAR.
>>
>> - I had one doubt about the scope of the marshaller. I gave it 
>> @Scope(Scopes.GLOBAL) since it'd be something shared among all caches. 
>> Now, I assume its @Stop method would be called when all caches are 
>> finished and the CacheManager is stopped? Wanted to make sure nothing 
>> is leaked!.
>>
>> - Application level versioning (VAM) is not yet supported in JBMAR but 
>> David is happy to listen for ideas. I'll address that for Beta1.
>>
>> - For Beta1, I'd like David to have a look at what I've done and see 
>> if he can review it and then do perf tests to see whether this new 
>> implementation is faster than our current one. If it is, next step 
>> would be to design a way for people to extend/modify via configuration 
>> magic numbers for their classes, provide Externalizers for their own 
>> classes...etc.
>>
>> Cheers,
>