Re: [infinispan-dev] First version of JBoss Marshalling based Marshaller
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,