Re: [jbosscache-dev] migrating data stored in 1.x format to VAM format

Manik Surtani wrote: > On 5 Feb 2007, at 19:57, Galder Zamarreno wrote: > >> Quick (but a bit lengthy :( ) update on this: >> >> - I've created a new Marshaller called Legacy1xMarshaller (anyone's >> got a better name?) which extends o.j.c.m.AsbtractMarshaller that >> would do the job of marshalling stuff in the 1.x fashion. This is to >> be used by JDBCCacheLoader and FileCacheLoader if configured to use >> 1.x marshalling. This has the benefit that the code in these cache >> loaders only have to do getMarshaller().whatever... , making it very >> simple to switch from VAM to Legacy Marshaller. > > I presume the VAM would transparently flip between marshallers, based > on the version short at the head of the stream? The problem is that 1.x marshalling for cache loaders did not have version numbers at the start, it was plain java serialization. Can you expect VAM to detect that? That's why I thought of a Marshaller instance in AbstractCacheLoader that would either use VAM or the Legacy one. We could however assume that if VAM does not find version number, it tries to use Legacy one. As you said later in the email, it seems like 1.4.x dealt with this similar situation. I'll look at it. > >> >> - In order to do this, I need to add a new method to >> o.j.c.m.Marshaller called objectToStream(OutputStream). The reason >> for doing is so that FileCacheLoader just needs to call >> getMarshaller().objectToStream() when it's trying to store data. This >> will avoid having an if statement in storeAttributes() checking which >> Marshaller is used, and calling objectToObjectStream with the >> corresponding ObjectOutpuStream. > > Again, isn't this already in the VAM? Not for OutputStream. You have objectToObjectStream(Object obj, ObjectOutputStream out) and objectFromStream(InputStream is), but not objectToStream for OutputStreams such as FileOutputStream. > >> >> - The decision maker for which Marshaller to use is to be done in >> AbstractCacheLoader which will store the Marshaller used by >> CacheLoader. getMarshaller() would decide upon configuration, which >> Marshaller to use, whether the default cache.getMarshaller() which is >> VAM or the legacy one, making it quite clean to switch from to another. > > Look at the VAM in the 1.4.x tree - it deals with "legacy support" to > deal with JBC 1.2.x and 1.3.x for RPC calls. (removed in 2.x since > the legacy support was no longer needed). Could easily be > re-introduced if needed to supportr legacy marshalling for CLs. Ok, i'll definitely have a look at that. > >> >> - Configuration wise, I created Legacy1xMarshallingCacheLoaderConfig >> (I couldn't come up with a better name!) which extends >> IndividualCacheLoaderConfig. JDBCCacheLoaderConfig and >> FileCacheLoaderConfig will extend >> Legacy1xMarshallingCacheLoaderConfig instead. > > Could drop the 1x in the name, I suppose? :-) No probs :) > >> >> - Inside Legacy1xMarshallingCacheLoaderConfig, I search for >> cache.loader.marshalling.1.x (name again!) boolean property in the >> <properties> section. If true, it uses legacy marshalling, and if >> false, which is default value, VAM. >> >> - I have extended CacheLoaderTestsBase to create >> FileCacheLoaderLegacyMarshallingTest which tests the FileCacheLoader >> with legacy marshalling. I'll be doing the same for JDBCCacheLoader. >> >> - Finally and one of the most important aspects, previous marhalling >> relies on these classes: >> >> org.jboss.invocation.MarshalledValue; >> org.jboss.invocation.MarshalledValueInputStream; >> >> Which used to be located in jboss-minimal.jar in 1.x. There's v >> similar classes in AOP but not the same, so I'm gonna be creating a >> legacy directory in lib with this library. To avoid compile time >> dependency, Legacy1xMarshaller will be instantiated via reflection, >> so only people who actually use this will need this library. The >> library has no conflicts with existing 2.x libraries. > > Look at the jboss-common-core jar and particularly JBCOMMON-8 in JIRA. > So, did you test whether you could read data written with JDBCCacheLoader wiht MV classes with a JDBCCacheLoader not using MV classes? That's one of the tests I wanted to do to see whether this classes were necessary. jboss-common-core.jar contains MarshalledValueOutputStream and MarshalledValueInputStream so that wouldn't be a problem for FCL. JDBCCacheLoader on the contrary, wrapped the node in MarshalledValue and the wrote it as an ObjectOutputStream. I'll look at the commons code to see whether it's the same which I guess might be. There's a MarshalledValue in aop libraries but quick glance at the code showed that it's slightly different. >> >> The last problem is that these two classes access >> org.jboss.logging.Logger that used to be in jboss-common.jar. Now >> this jar certainly classes with jboss-common-core.jar in 2.x, so >> what's I've done is get jboss-logging-spi.jar 2.0.2.GA and put it in >> the legacy directory. >> >> So, we end up having two legacy libraries in lib/legacy but they're >> only needed at runtime if using 1.x marhalling. I guess it's the >> price to pay to make customer's life a bit easier. >> > > Trying to avoid a legacy jar dir ... like I said, see if the MV and > MVIS can be in jboss-common-core (without JBoss Logging deps!) Yeah defo, we wanna avoid any legacy jars. > >> The other alternative would be for 1.x marshaller not to use this >> org.jboss.invocation.* classes and just write to Object streams but I >> think these classes have an impact in the format of the marshalled >> data. Brian, do you know a bit more about the role of these classes? >> >> A bit more complicated than initially expected but I can't see any >> easier way of providing backwards compatibility. Hopefully we should >> be able to phase it out asap, 3.x? :) >> >> What this has shown as well is how different CacheLoaders marshalled >> things in a slightly different way which makes having a common >> framework for this even more necessary, i.e. VAM. :D >> >> Hope you're not snoring by now ;) >> >> If you have better ideas for the naming I used, speak up :) >> >> Galder Zamarreño >> Sr. Software Maintenance Engineer >> JBoss, a division of Red Hat >> >> -----Original Message----- >> From: jbosscache-dev-bounces(a)lists.jboss.org >> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder >> Zamarreno >> Sent: 31 January 2007 01:01 >> To: Manik Surtani >> Cc: jbosscache-dev(a)lists.jboss.org >> Subject: RE: [jbosscache-dev] migrating data stored in 1.x format to >> VAM format >> >> +1, VAM should be the default. >> >> Only people who are resilient to change their existing stores to VAM >> should use the 1.x option, which would need explicitly definition. >> >> Galder Zamarreño >> Sr. Software Maintenance Engineer >> JBoss, a division of Red Hat >> >> >> -----Original Message----- >> From: Manik Surtani [mailto:manik@jboss.org] >> Sent: 30 January 2007 22:55 >> To: Galder Zamarreno >> Cc: jbosscache-dev(a)lists.jboss.org >> Subject: Re: [jbosscache-dev] migrating data stored in 1.x format to >> VAM format >> >> I see what you mean, although I would like the default to be to use >> the VAM. >> >> -- >> Manik Surtani >> >> Lead, JBoss Cache >> JBoss, a division of Red Hat >> >> Email: manik(a)jboss.org >> Telephone: +44 7786 702 706 >> MSN: manik(a)surtani.org >> Yahoo/AIM/Skype: maniksurtani >> >> >> >> On 30 Jan 2007, at 20:45, Galder Zamarreno wrote: >> >>> Actually, the more I think about this, the less I like the idea of >>> switching the marshalling from 1.x to 2.x at the CacheLoaders >>> level, or at least forcing them to do so. >>> >>> Customers that want to use JBossCache 2.x might be reluctant to >>> migrate their data from one format to the other. I can see how an >>> existing customer might think this is a proper pain in the ass, >>> independent of the benefits, and might reduce adoption among them. >>> >>> We want to remove barriers upgrading, but at the same time, we want >>> new customer to use new marshalling, so I'd actually implement the >>> possibility to use 1.x marshalling which is plan java serialization >>> at the CacheLoader level. This could easily achieved adding a >>> property to the <properties> section. >>> >>> Just note that this does not apply to the marshalling done at >>> replication level as there's no hard data that needs migrating. >>> >>> Galder Zamarreño >>> Sr. Software Maintenance Engineer >>> JBoss, a division of Red Hat >>> >>> -----Original Message----- >>> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev- >>> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno >>> Sent: 25 January 2007 13:07 >>> To: jbosscache-dev(a)lists.jboss.org >>> Subject: [jbosscache-dev] migrating data stored in 1.x format to >>> VAM format >>> >>> Hi all, >>> >>> I'm deferring http://jira.jboss.com/jira/browse/JBCACHE-879 to >>> BETA2 because I still need to write this: http://jira.jboss.com/ >>> jira/browse/JBCACHE-882 >>> >>> The reason I'm deferring it is because I can't see a >>> straightforward way of doing such thing right now. Ideally, you >>> should be able run a 1.x version (cache1) and a 2.x version >>> (cache2) of JBC in the same VM so that you can do a loop of >>> cache1.get() and call cache2.put(). However, I have doubts that >>> that this approach will be free of class loading issues. What do >>> you think? >>> >>> I was wondering whether Region based could help here, but I can't >>> see right now how this could be done. >>> >>> Something I had in mind is having the capability of to start a >>> cache with either 1.x marshalling or VAM marshalling, but oriented >>> at being used only at the cache loader level. It wouldn't make much >>> sense for replication because there's no hard data there. >>> >>> >>> I thought that you could start two instances of cache 2.x, first >>> with 1.x. marshalling and the other one with VAM both pointing to >>> different JDBCCacheLoader stores. You could then get from the first >>> using normal mmarshalling and put in the second one which has VAM >>> marshalling active, what do you think? >>> >>> If you like the approach, I should be have it ready by BETA2. >>> >>> This last approach looks simpler to me, what do you think? >>> >>> Galder Zamarreño >>> Sr. Software Maintenance Engineer >>> JBoss, a division of Red Hat >>> >>> >>> >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>> >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >> >> >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >