RE: Thoughts on JBCACHE-794?
by Ben Wang
Please go ahead. I don't see any adverse effect so far.
Thanks,
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, October 27, 2006 7:27 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Thoughts on JBCACHE-794?
Hey Ben,
Any thoughts on this issue?
http://jboss.org/index.html?module=bb&op=viewtopic&p=3979697
Do you (or anyone else) see any adverse effects that could arise by setting the lock acquisition timeout on the eviction thread to 0? It would remove the chance of this deadlock occuring, plus improve performance in general as evictions will happen in a more timely fashion.
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
17 years, 6 months
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Ben Wang
+1 for another version number.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
Sent: Friday, October 27, 2006 7:51 PM
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
Has any testing been done on 812 ? Vlad ?
Yes, I think this warrents another version number, not just an SP
Manik Surtani wrote:
> Brian and I have been speaking about adding JBCACHE-812 to the next
> 1.4.x release, the purpose being that there may be an AS 4.2.0 release
> which may allow us to include the MUX.
>
> Since this is a fairly large feature change, I feel it is beyond the
> scope of an SP and would warrant a bump up in version numbers. And
> TBH, so does JBCACHE-756, since it involves a new JBoss Serialization
> jar.
>
> Thoughts on this? Pls respond soon as I hope to cut the next 1.4
> release next week.
>
> 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
>
--
Bela Ban
Lead JGroups / Manager JBoss Clustering Group JBoss - a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 6 months
1.4.0.SP2 or 1.4.1?
by Manik Surtani
Brian and I have been speaking about adding JBCACHE-812 to the next
1.4.x release, the purpose being that there may be an AS 4.2.0
release which may allow us to include the MUX.
Since this is a fairly large feature change, I feel it is beyond the
scope of an SP and would warrant a bump up in version numbers. And
TBH, so does JBCACHE-756, since it involves a new JBoss Serialization
jar.
Thoughts on this? Pls respond soon as I hope to cut the next 1.4
release next week.
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
17 years, 6 months
Thoughts on JBCACHE-794?
by Manik Surtani
Hey Ben,
Any thoughts on this issue?
http://jboss.org/index.html?module=bb&op=viewtopic&p=3979697
Do you (or anyone else) see any adverse effects that could arise by
setting the lock acquisition timeout on the eviction thread to 0? It
would remove the chance of this deadlock occuring, plus improve
performance in general as evictions will happen in a more timely
fashion.
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
17 years, 6 months
JBCACHE-710
by Manik Surtani
Ben,
Trying to understand the problem here, assuming an AS restart leaves
the FCL .dat file in an inconsistent state, wouldn't the loader.remove
() throw an exception anyway? And this would propagate up, since the
remove() method in the ActivationInterceptor does throw an Exception ...
--
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, 6 months
Re: Beta Release for AS 5
by Manik Surtani
I agree, we too would have > 1 beta.
TBH, I'm ready for an Alpha for pretty early next week, how about the
rest of you guys?
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
On 27 Oct 2006, at 02:20, Ben Wang wrote:
> Looks like AS will have beta1 and beta2 releases, so I am wondering
> if we can follow the same here? :-) Given that the alpha won't be
> out untill next week, my concern is a real "beta" by 11/15 will be
> a bit too short given this is a major release.
>
> From: Bela Ban
> Sent: Friday, October 27, 2006 4:29 AM
> To: Brian Stansberry
> Cc: Manik Surtani; Ben Wang; Vladimir Blagojevic
> Subject: Re: FW: Beta Release for AS 5
>
> +1 from me, but Manik's the one to decide really...
>
> Brian Stansberry wrote:
>> Do you guys see any problem having a 2.0.0.Beta available by say
>> 11/15 or so? It would just need to support the existing AS use
>> cases; i.e. anything extra we want for 2.0.0.GA doesn't need to be
>> in it.
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
>>
>> From: Andy Miller
>> Sent: Tuesday, October 24, 2006 7:37 PM
>> To: Scott M Stark; Anil Saldhana; Thomas Diesler; Jason T. Greene;
>> Carlo de Wolf; Bill Burke; Adrian Brock; Brian Stansberry
>> Subject: Beta Release for AS 5
>>
>> Guys,
>>
>> Based on my earlier thread to gather input for a Beta release
>> of AS 5 we arrived at a hard date of December 8th. That Beta
>> would have the basics working, but not be the final design of the
>> MC/Deployer stuff, and the profile service would not have the
>> management API defined and implemented. We will follow with a
>> second Beta which will clean-up everything, incorporate any
>> refactoring necessary, and add the management API for JBoss ON to
>> the profile service.
>>
>> Since then, there has been some additional discussion about can we
>> release something by JBoss World, which as you know, is November
>> 20th.
>>
>> So here's the challenge. Release an AS 5 that has deployers on
>> the new MC that work, has decent TCK coverage for EJB 3 and WS
>> working, and has the JGroups/JBoss Cache releases integrated, all
>> from HEAD by November 20th.
>>
>> Let's accept this challenge, and if you guys can pull it off, I'll
>> find a way to reward each of you for the effort.
>>
>> Thanks.
>>
>> Andrig (Andy) Miller
>> VP, Engineering
>> JBoss, a division of Red Hat
>
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
17 years, 6 months
Eliminate need for jboss-serialization.jar if it's not used
by Manik Surtani
On 26 Oct 2006, at 17:11, Brian Stansberry wrote:
> It's configurable via a system property (serialization.jboss). I
> see now
> the default is to use JBoss serialization; thought it was to use Java
> serialization.
>
We switched the defaults around prior to release. We should be using
jboss-ser where poss. because of the perf benefits, but there were
issues with it in 1.4 betas hence my switching the default to java
serialization till Clebert released JBoss Serialization 1.0.1.
> Sure, if we want to force JBoss serialization, then this JIRA is
> irrelevant.
>
> Re: reason to have it be configurable, it provides a fallback
> option if
> there is any issue with jboss serialization. IMHO, that's valid.
>
If you feel this is a useful option, then OK.
>
> Manik Surtani wrote:
>> I don't believe this is a configurable option ... ?
>> Is there any good reason to make it so?
>>
>>
>>> From: "Brian Stansberry (JIRA)" <jira-events(a)jboss.com>
>>> Date: 26 October 2006 15:12:41 BDT
>>> To: manik.surtani(a)jboss.com
>>> Subject: [JBoss JIRA] Created: (JBCACHE-815) Eliminate need for
>>> jboss-serialization.jar if it's not used
>>>
>>> Issue (View Online)
>>>
>>> Key: JBCACHE-815
>>> Issue Type: Task
>>> Status: Open
>>> Priority: Minor
>>> Assignee: Manik Surtani
>>> Reporter: Brian Stansberry
>>> Operations
>>>
>>> View all
>>> View comments
>>> View history
>>>
>>> Eliminate need for jboss-serialization.jar if it's not used
>>> Updated: 26/Oct/06 10:11 AM Created: 26/Oct/06 10:11 AM
>>> Project:JBoss Cache Components: Replication
>>> Affects Versions: 1.4.0.SP1, 1.4.0
>>> Security Level: Public (Everyone can see)
>>>
>>> Description
>>> If we're going to stick making use of JBoss serialization a
>>> configurable option, we should refactor
>>> ObjectSerializationFactory so
>>> no jboss-serialization classes are loaded if it's not used.
>>> Allows users to drop one more jar from their footprint.
>>>
>>>
>>> This message was automatically generated by Atlassian JIRA
>>> Enterprise
>>> Edition, Version: 3.6.2-156 - Bug/feature request.
>>> If you think it was sent incorrectly, contact one of this server's
>>> administrators.
>
>
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
17 years, 6 months
Consistent factory method
by Ben Wang
Manik,
This is a minor issue raised by Brian when he is constructing the bean file for AS5. Currently, we have slight way of creating a cache instance from the factory method.
In Cache, we do:
CacheFactory factory = new DefaultCacheFactory();
CacheSPI tree = (CacheSPI) factory.createCache(c, false);
While in PojoCache, we do:
cache_ = PojoCacheFactory.createInstance(configFile, false);
Nothing wrong with both approaches but maybe we should be consistent in both cache instances. And I don't mind to switch if needed. For me, the reason that I did it in the first place is I don't forsee a pluggable cache instance for PojoCache. And if needed, another Factory can be used as well.
I thought originally with your approach, there is more control over the lifecycle methods. But now it is probably not needed there. Any other reason to stick with your approach?
Thanks,
-Ben
17 years, 6 months
Conf call: JBoss Cache and Hibernate
by Manik Surtani
When: Friday, 27th October, 13:00 - 14:00 UTC/GMT
Topics to cover:
1) Detail of Hibernate usage of JBoss Cache
2) Use of a putFailFast() equivalent to achieve this - what are the
characteristics of this method?
3) Optimistic locking and data versioning issues with the Query Cache
4) Invalidation issues and edge cases
5) AOB?
The goal of this session is to understand what steps need to be taken
by both Hibernate and JBoss Cache to improve integration between the
2 products.
Current confirmed attendees: Manik Surtani, Steve Ebersole, Max
Andersen, Owen Taylor, Emmanuel Bernard. All else welcome.
Dial-in details:
Participant passcode
246960
Dial-in numbers
Toll free
1-866-863-0570
Toll/International
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
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, 6 months
New cruisecontrol target for JBossCache 2.0.0
by Manik Surtani
FYI, I have asked QA to set up another target for cruise control -
one that runs a build from HEAD under JDK 1.4.0.
http://jira.jboss.com/jira/browse/JBQA-518
The purpose behind this is that although HEAD is baselined on JDK 5
(for standalone use and use in AS 5), there would still be use-case
where this would need to work with JDK 1.4.x, particularly since
Hibernate is still baselined on 1.4.x.
This test target runs "all-unittests-retro-cc" as opposed to "all-
unittests-cc", the differences being:
1) Does not run pojocache tests. Pojocache is Java 5 only.
2) Adds jbossretro dependencies to the test suiute.
3) Retroweaves compiled srcs and tests before running test suite
using jbossretro.
In addition, "build dist" now creates an additional JBossCache-core-
JDK14-X.Y.Z.A.zip package, which contains retroweaved binaries +
jbossretro dependency jars.
This was all a part of
http://jira.jboss.com/jira/browse/JBCACHE-664
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
17 years, 6 months