Re: JBoss Cache and Hibernate Integration
by Brian Stansberry
OK, Monday 9/26 at 10:00 AM EST it is. Details below. Manik, you had a
problem today joining a conf Ram set up using the # below; you guys
overseas might test it during your Monday and if there's an issue send
me a note by 9:30 EST or so.
Main things to discuss are on
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment.
Participant Passcode: 426146
Listen-only Passcode: 4261469
Phone Numbers:
Toll free: 1-866-863-0570
Toll: 1-719-785-1839
Local (Australia, Sydney): + 61 282078345
Local (Austria, Vienna): + 43 2 682 205 6473
Local (Belgium, Brussels): + 32 2 789 7404
Local (Denmark, Copenhagen): + 45 32 71 49 78
Local (France, Paris): + 33 1 7304 1405
Local (Germany, Frankfurt): + 49 69 36507 2085
Local (Hong Kong): + 852 300 80 305
Local (Ireland, Dublin): + 353 1 436 7678
Local (Italy, Milan): + 39 02 896 291 98
Local (Italy, Rome): + 39 06 452 108 385
Local (Italy, Turin): + 39 01 121 792 109
Local (Japan, Tokyo): + 813 4455 1255
Local (Netherlands, Amsterdam): + 31 20 794 8154
Local (Singapore): + 65 64193725
Local (Spain, Barcelona): + 34 93 492 3169
Local (Spain, Madrid): + 34 91 788 9790
Local (Spain, Valencia): + 34 96 047 3045
Local (Sweden, Stockholm): + 46 8 5052 0391
Local (Switzerland, Geneva): + 41 22 592 7323
Local (Switzerland, Zurich): + 41 43 456 9168
Local (UK, London): + 44(0) 207 663 2215
International toll free (Argentina): 0 800 666 2108
International toll free (Australia): 1 800 069 181
International toll free (Austria): 0 800 295 856
International toll free (Bahamas): 1 800 389 0432
International toll free (Belgium): 0 800 73 378
International toll free (Brazil): 0 800 891 9738
International toll free (Chile): 123 0020 6923
International toll free (China, Northern Region): 10 800 714 0955
International toll free (China, Southern Region): 10 800 140 0931
International toll free (Colombia): 01 800 518 0492
International toll free (Costa Rica): 0 800 015 0454
International toll free (Czech Republic): 800 142 019
International toll free (Denmark): 80 887 261
International toll free (Dominican Republic): 1 888 751 4409
International toll free (France): 0 800 908 359
International toll free (Germany): 0 800 182 1595
International toll free (Greece): 00 800 161 2205 1625
International toll free (Hong Kong): 800 933 791
International toll free (Hungary): 06 800 184 16
International toll free (India): 000 800 1006 397
International toll free (Indonesia): 001 803 017 1625
International toll free (Ireland): 1 800 760 193
International toll free (Israel): 1 80 945 1625
International toll free (Italy): 800 870 328
International toll free (Japan): 00531 16 0605
International toll free (Latvia): 800 2487
International toll free (Lithuania): 8 800 9 00 62
International toll free (Luxembourg): 800 2 5774
International toll free (Malaysia): 1 800 812 593
International toll free (Mexico): 001 800 514 1625
International toll free (Monaco): 800 93 297
International toll free (Netherlands): 0 800 022 2653
International toll free (New Zealand): 0 800 450 433
International toll free (Norway): 800 192 42
International toll free (Panama): 00 800 226 1625
International toll free (Poland): 00 800 111 48 26
International toll free (Portugal): 800 819 366
International toll free (Russia): 810 800 2535 1012
International toll free (Singapore): 800 101 1767
International toll free (Slovenia): 0 800 80802
International toll free (South Africa): 0 800 999 571
International toll free (South Korea): 003 0813 1634
International toll free (Spain): 900 987 056
International toll free (Sweden): 02 079 5157
International toll free (Switzerland): 0 800 562 271
International toll free (Thailand): 001 800 156 205 1625
International toll free (Trinidad-Tobago): 1 800 205 1625
International toll free (UK): 0 800 051 3876
International toll free (Uruguay): 0004 019 0088
International toll free (Venezuela): 0 800 100 5202
Manik Surtani wrote:
> +1
>
>
> On 22 Feb 2007, at 18:19, Steve Ebersole wrote:
>
>> Brian Stansberry wrote:
>>> Sent this out a while back, but the conf call didn't come off due to
>>> scheduling issues. Time to try again.
>>>
>>> How does next Monday, Feb 26 at 10:00 AM EST sound? Once we have an
>>> agreed time I'll send out conference call details. Those cc'ed on
>>> the mailing lists are welcome to join in.
>>>
>> Also including Owen explicitly, since I am not sure if he is part of
>> either list.
>>
>> That date/time is fine for me.
>
> --
> 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
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 7 months
RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format
by Galder Zamarreno
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.
- 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.
- 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.
- Configuration wise, I created Legacy1xMarshallingCacheLoaderConfig (I couldn't come up with a better name!) which extends IndividualCacheLoaderConfig. JDBCCacheLoaderConfig and FileCacheLoaderConfig will extend Legacy1xMarshallingCacheLoaderConfig instead.
- 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.
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.
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
17 years, 8 months
Jarring jars
by Manik Surtani
The list of jars JBoss Cache ships with is growing. And this is, as
you can imagine, a PITA.
* Core libs - commons-logging, jgroups, concurrent (needed by JGroups
< 2.5), jboss-serialization, jboss-common-core
* Pojocache libs - trove, jboss-aop, javassist, microcontainer jars
(4 jars here!!)
* JDK1.4-compat distro: 4 extra jars here
* Optional jars: c3p0 (DB connection pooling for standalone use),
bdbje and jdbm for specific cache loaders.
Looking at how Bill's packaged libs up for embedded EJB, he's got an
ant task that jars up all the jars into a single file.
<jar jarfile="UberJar.jar">
<zipfileset file="jar1.jar" />
<zipfileset file="jar2.jar" />
...
</jar>
What do you think? This way the JBoss Cache distro can ship with a
minimal number of jars:
* Core: jboss-cache.jar, jboss-cache-deps.jar
* PojoCache: jboss-cache.jar, jboss-cache-deps.jar, pojo-cache-deps.jar
* JDK1.4-compat: jboss-cache.jar, jboss-cache-deps-JDK14.jar
* Optional jars
What do you guys think of this approach? It may mean a replication
of jars (you may already have commons-logging or jboss-serialization
in your libs) but these jars are small and not a huge impact on
size. What about wanting to swap out jars, e.g., JGroups?
Thoughts?
--
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
17 years, 8 months
Mircea's RedcdRecJDBCCacheLoader
by Manik Surtani
Guys,
I'm pretty keen on including Mircea's RedcdRecJDBCCacheLoader in 2.0.0:
1) Performance improvement based on removal of recursive DB calls
(uses linear calls instead - see Mircea's previous posts)
2) Backward compatible with the existing JDBC cache loader
3) No specific use case why the old JDBCCacheLoader should be used
instead of this.
So my question to you is this:
Do we drop the existing JDBCCacheLoader and rename the
RedcdRecJDBCCacheLoader (hate that name!) to JDBCCacheLoader?
Comments?
--
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
17 years, 9 months
Re: [jbosscache-dev] AOPC Ant task and tmp directories
by Manik Surtani
On 27 Feb 2007, at 16:49, Ryan Campbell wrote:
> >Probably caused by QA locking down /tmp:
>
> Actually /tmp is not locked down. It is likely that someone else
> ran this test before you, and the test did not clean up after
> itself. Ergo, you are unable to overwrite their file because they
> own it.
Well, see my attempts at "touch /tmp/test.file" further below ... :-)
>
> Tests should not write to tmp, or even java.io.tmpdir. Tests
> should write to output/tmp or whatever directory under their build
> output they desire. Additionally, tests should be careful to clean
> up things like temporary files during tearDown() so that developers
> do not see invalid results across multiple runs in their own
> environment.
I agree. This is basically something in the aopc Ant task that will
need fixing. It has nothing to do with unit tests, this happens when
building pojocache.
Cheers,
Manik
>
> Manik Surtani wrote:
>> Guys,
>>
>> I'm seeing something with the AOPC ant task when running on the
>> lab servers (dev02). It seems to hardcode using /tmp as a temp
>> directory rather than java.io.tmpdir (which i've set to /home/
>> msurtani/tmp in the example below).
>>
>> java.lang.RuntimeException: java.io.IOException: Permission denied
>> at org.jboss.aop.ant.AopC.logAndAddFilesToCompile
>> (AopC.java:488)
>> at org.jboss.aop.ant.AopC.execute(AopC.java:328)
>> at org.apache.tools.ant.UnknownElement.execute
>> (UnknownElement.java:275)
>> at org.apache.tools.ant.Task.perform(Task.java:364)
>> at org.apache.tools.ant.Target.execute(Target.java:341)
>> at org.apache.tools.ant.Target.performTasks(Target.java:369)
>> at org.apache.tools.ant.Project.executeTarget(Project.java:
>> 1214)
>> at org.apache.tools.ant.Project.executeTargets
>> (Project.java:1062)
>> at org.apache.tools.ant.Main.runBuild(Main.java:673)
>> at org.apache.tools.ant.Main.startAnt(Main.java:188)
>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:
>> 196)
>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:
>> 55)
>> Caused by: java.io.IOException: Permission denied
>> at java.io.UnixFileSystem.createFileExclusively(Native
>> Method)
>> at java.io.File.checkAndCreate(File.java:1345)
>> at java.io.File.createTempFile(File.java:1434)
>> at java.io.File.createTempFile(File.java:1471)
>> at org.jboss.aop.ant.AopC.logAndAddFilesToCompile
>> (AopC.java:457)
>> ... 11 more
>>
>> Probably caused by QA locking down /tmp:
>>
>> [msurtani@dev02 JBossCache200]$ touch /tmp/test.file
>> touch: creating `/tmp/test.file': Permission denied
>> [msurtani@dev02 JBossCache200]$
>>
>> Any plans to change this?
>>
>> Cheers,
>> --
>> 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
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>
>
--
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
17 years, 9 months
