Logging exceptions
by Vladimir Blagojevic
Hi,
Sometimes I come across a case where a good design principle for a flow
of control is to raise an exception. Exceptions are usually logged and
stack trace is dumped. In some of these cases exceptions happen due to
expected circumstances (i.e request to activate region when region is
not active) and so on. I am getting an impression (maybe a false one)
that users freak out when the see stack traces and thus I am reluctant
to raise an Exception in some of these cases and make a workaround.
What do you guys do about this problem? Is there a way to have a generic
catch clause for Exception but somehow indicate if stacktrace should be
dumped or not to a logger? Or should I just forget about this impression
(of freaking out users) and raise exceptions whenever a good design
dictates it?
Regards,
Vladimir
17 years, 7 months
Nodes and activation problem
by Vladimir Blagojevic
Hey,
There is something weird going on with region activation (partial state
transfer). As you can see on CC test
org.jboss.cache.statetransfer.StateTransfer200Test#testPartialStateTrans
fer fails.
Assert that fails is:
assertEquals("Incorrect name for /a/b", JOE, cache2.get(A_B, "name"));
Since cache2 claims that node A_B does not have key name. However, looks
at these statements
and their output just prior to this assert.
System.out.println("Region A_B on cache2: " + cache2.getRegion(A_B,
false));
Node child = cache2.getChild(A_B);
System.out.println(child.getKeys());
System.out.println(child.getData());
System.out.println(child.get("age"));
System.out.println(cache2.get(A_B, "name"));
Region A_B on cache2: RegionImpl{fqn=/a/b; active=true; eviction=false;
timerThreadRegistered=false}
[{age=20, name=JOE}]
{{age=20, name=JOE}=true}
null
null
Just wanted to bring this to attention. Could it be state transfer
problem or
something in these last Node API changes?
Cheers,
Vladimir
17 years, 7 months
JBCACHE-905 - code coverage for 1.4.1
by Hany Mesha
Hi all,
I've run Clover against Branch_JBossCache_1_4_0 and the initial
generated report and statistics are posted on the wiki at
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCache14xCodeCoverageAnalysis
We have an overall coverage of 89.6 % which is pretty good number for
initial report considering that there are test cases failing. If those
test cases get fixed, I'll be able to produce more accurate report and
therefore I'll be able to identify areas that are not covered in the
test suite and write test cases to cover those in the next few days
before releasing 1.4.1 GA.
Please let me know if you're working on fixing one or more test case in
the 1.4 branch and when you think you'll check that fix in?
Thanks,
-Hany
Hany M. Mesha
Sr. Software Engineer, Consultant
Novell Identity Management Engineering
Toronto, Canada
hmesha(a)novell.com
Mobile: 416-456-6945
skype: hanymesha
Novell, Inc.
SUSE® Linux Enterprise 10
Your Linux is ready
http://www.novell.com/linux
17 years, 7 months
VAM integration in JDBCCL - updating an empty node from database results on a put() on Collections.emptyMap()
by Galder Zamarreno
Hi,
I'm in the process of integrating VersionAwareMarshaller with JBDCCacheLoader and I've found an issue in TreeCacheMarshaller200. unmarshallMap().
Let's say I make a put (single key/value pair) in the cache which results in an insert of a marshalled map in the db. I then call remove(key) which results on the map still being in the db but containing no data.
If I evict the data from memory and call put() again, unmarshallMap() would return Collections.emptyMap() which returns an immutable empty map. When I try putting my new data into the map, it throws java.lang.UnsupportedOperationException which is expected as the map is immutable.
I had a quick chat with Brian and the first solution was to check for isEmpty() but as Brian pointed out,
"If VAM is meant to be a general purpose tool, it needs to work in a general purpose way, if code that uses it needs to understand it's internal details and code around them, that's improper"
He also said: "well VAM is just assuming that the only purpose of the map is to be an argument in a put call. if VAM is to be general purpose it can't make such assumptions, or needs to expose an API to turn them on/off per request"
I think Brian is right. Currently, JDBCCL checks values from JDBCCL.loadNode() based on the contract of this method, and therefore, should not really now what could come from VAM.
Thoughts?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
17 years, 7 months
RE: [jbosscache-dev] Marshalling for state transfer in HEAD
by Vladimir Blagojevic
Hey,
I am not 100% sure if we need this for compatibility. Am I correct to
assume that since we write/read only NodeData objects to/from streams
(in HEAD) then we do not have to worry about versions any more as long
as we keep NodeData backward compatible (which we do).
Let me know.
Vladimir
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Thursday, December 14, 2006 11:57 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Marshalling for state transfer in HEAD
>
> I've just noticed that marshalling of nodes for transferring
> state in HEAD is hand-wired.
>
> We should do this thru the VersionAwareMarshaller framework
> we have in place for other comms as well as marshalling to
> cache loaders, to benefit from the data streams being
> version-aware as well as being more efficient by making use
> of magic numbers instead of class headers + using JBoss
> Serialization where useful.
>
> I've created a JIRA task for this, Vlad, perhaps you could do
> this alongside the SST stuff you've got in HEAD?
>
> http://jira.jboss.com/jira/browse/JBCACHE-908
>
> 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
>
17 years, 7 months
Marshalling for state transfer in HEAD
by Manik Surtani
I've just noticed that marshalling of nodes for transferring state in
HEAD is hand-wired.
We should do this thru the VersionAwareMarshaller framework we have
in place for other comms as well as marshalling to cache loaders, to
benefit from the data streams being version-aware as well as being
more efficient by making use of magic numbers instead of class
headers + using JBoss Serialization where useful.
I've created a JIRA task for this, Vlad, perhaps you could do this
alongside the SST stuff you've got in HEAD?
http://jira.jboss.com/jira/browse/JBCACHE-908
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, 7 months
RE: JBoss Cache 1.4.1.CR1 tagged
by Ryan Campbell
Shelly is going to be handling this release. Thanks Shelly!
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Wednesday, December 13, 2006 10:11 AM
> To: jbosscache-dev(a)lists.jboss.org
> Cc: QA
> Subject: JBoss Cache 1.4.1.CR1 tagged
>
> Hi guys
>
> I've tagged 1.4.1.CR1 as JBossCache_1_4_1_CR1.
>
> See
>
> http://tinyurl.com/yybujq
>
> for release notes.
>
> 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, 7 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJB Container] - Problemwith order of entity cache operations with Hibernate
by Brian Stansberry
I've resurrected this thread on the JBC Dev Forum at
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97247.
This is suddenly more urgent because JBossTS is going into AS 4.2.
Emmanuel Bernard wrote:
> No, not possible right now.
>
> This problem roots to JTA, we really should push the ability to:
> 1. guaranty synchronization ordering
> 2. query/alter the synchronization list
> in a standard way.
>
> 1. is not possible today and
> javax/transaction/TransactionSynchronizationRegistry is way
> too limited 2. is useful when writing frameworks on top of
> JavaEE as a way to keep state / avoid multiple
> synchronization on a per transaction basis.
>
>
>
>
> Manik Surtani wrote:
>>
>> Not sure, cc'ing Hibernate-all. Even if there was such an ordered
>> sync handler, we'd have to expose a mechanism to have this injected.
>> Perhaps via the Runtime. --
>> 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 17 Nov 2006, at 15:43, Brian Stansberry wrote:
>>
>> <SNIP />
>>
>>> That's how we find such a thing. Anyone have any good thoughts on
>>> what to do about it? Perhaps Hibernate exposes something like JBC's
>>> OrderedSynchronizationHandler, which the JBC integration can use to
>>> insert it's synchronization at the correct point?
>>
>> Manik Surtani wrote:
>>
>>> Hmm, the *correct* approach to dealing with this would be to put
>>> together a series of integration tests for JBoss Cache and
>>> Hibernate, exercising such scenarios with different TMs, and making
>>> sure these are run with every release of Hibernate and JBC. Either
>>> that, or we assume the EJB3 test suite covers this, and I presume
>>> this is how you uncovered this issue?
>>>
>>>
>>>
>>>> FYI; just posted on the EJB3 forum.
>>>>
>>>> bstansberry(a)jboss.com wrote:
>>>>
>>>>> There appears to be a difference in behavior between JBossTM and
>>>>> JBossTS that's leading to failures with JBoss Cache as the 2nd
>>>>> level entity cache.
>>>>>
>>>>> JBC handles replication of transaction-scoped cache changes by
>>>>> registering as a transaction Synchronization and replicating the
>>>>> changes during the beforeCompletion() callback. This is failing
>>>>> with JBossTS because the beforeCompletion() callback is being
>>>>> executed *before* the Hibernate flush activity that updates the
>>>>> cache. No activity at time of beforeCompletion() == no
>>>>> replication of the tx's changes.
>>>>>
>>>>> 2006-11-16 23:48:41,250 TRACE
>>>>> [org.jboss.cache.interceptors.TxInterceptor] Running
>>>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
>>>>> 2006-11-16 23:48:41,250 TRACE
>>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up
>>>>> transactional context. 2006-11-16 23:48:41,250 TRACE
>>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
>>>>> TransactionImple < ac, BasicAction:
>>>>>
>>> -3f57ff9b:a5b:455d4cd6:10 status:
>>>
>>>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
>>>>> 23:48:41,250 TRACE
> [org.jboss.cache.interceptors.TxInterceptor] No
>>>>> modifications in this tx. Skipping beforeCompletion() 2006-11-16
>>>>> 23:48:41,250 DEBUG
>>>>> [org.hibernate.event.def.AbstractFlushingEventListener]
>>>>> processing flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>>>> [org.hibernate.engine.Collections] Collection found:
>>>>>
> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
>>>>> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>>>> 23:48:41,265 DEBUG
>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed:
>>>>> 1 (re)creations, 0 updates, 0 removals to 1 collections ...
>>>>> followed by puts into the cache
>>>>>
>>>>> When I switched the AS back to using JBossTM, the problem went
>>>>> away -- the Hibernate flush activity occurred first, and then the
>>>>> beforeCompletion() call to JBC.
>>>>>
>>>>> I'm speculating that Hibernate is also using a Synchronization to
>>>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>>>> registered Synchronizations in a different order.
>>>>>
>>>>> At this point, replication of clustered EJB3 entities is
>>>>> basically broken.
>>>>>
>>>>> View the original post :
>>>>>
>>>>>
>>>> http://www.jboss.com/index.html?
>>>> module=bb&op=viewtopic&p=3986745#3986745
>>>>
>>>>>
>>>>> Reply to the post :
>>>>>
>>>>>
>>>> http://www.jboss.com/index.html?
>>>> module=bb&op=posting&mode=reply&p=398674
17 years, 7 months
JBoss Cache 1.4.1.CR1 tagged
by Manik Surtani
Hi guys
I've tagged 1.4.1.CR1 as JBossCache_1_4_1_CR1.
See
http://tinyurl.com/yybujq
for release notes.
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, 7 months
RE: [jbosscache-dev] RE: JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
These were checked in a few days back. I didn't close the JIRA 'cause
there were so many failures on cc it was hard for me to guarantee I
didn't cause a problem when I ran the testsuite. I'd compared my
results to cc and saw no regressions, so I think it was OK, so I'll go
ahead and close 874; we can re-open if the work on nailing down the
remaining failures shows something amiss.
Manik Surtani wrote:
> Brian,
>
> Do you want to check in your fixes for 874 (if you haven't already)?
> Getting close to a clean build on 1.4.x, with a few MUX and PojoCache
> failures remaining.
>
> Cheers,
>
>> Yeah, I'm looking into the CC failures today, there does seem to be a
>> proliferation of failures (almost 4% at the moment). --
>> 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 8 Dec 2006, at 04:36, Brian Stansberry wrote:
>>
>>> This change is made on 1.4 and HEAD.
>>>
>>> When I looked at it, the effiency gain from using a Set vs a List
>>> only exists with the locks collection. So that's the only one I
>>> changed to LinkedHashSet. The methods that add things to the other
>>> list fields (e.g. modifications) don't do a contains() check to see
>>> if what they are adding is already there, so they don't have the
>>> inefficiency. Presumably
>>> this means that with normal behavior the same object wouldn't get
>>> added twice to these lists. A cursory check showed that to be the
>>> case, and if it weren't I'd expect we'd have noticeable bugs. So, I
>>> decided not to change to other fields to LinkedHashSet -- didn't
>>> want to introduce issues by making a change. At least not in 1.4.
>>>
>>> I ran the testsuite and saw no regressions vs cc. But, there are a
>>> lot of failures now on cc, so I'm going to wait to close JBCACHE-874
>>> until we get some cleaner test runs.
>>>
>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>> Manik Surtani wrote:
>>>>> On 5 Dec 2006, at 19:29, Brian Stansberry wrote:
>>>>>
>>>>>> Manik Surtani wrote:
>>>>>>> Brian Stansberry wrote:
>>>>>>>> It's not a big deal if JBCACHE-874 doesn't go in 1.4.1.CR1, but
>>>>>>>> it would be nice to get it in so it's out in the wild longer
>>>>>>>> before the GA.
>>>>>>>
>>>>>>> Sorry yes, forgot about this.
>>>>>>>
>>>>>>
>>>>>> If you're delaying 1.4.1.CR1 for this, let me know, because at
>>>>>> this point I was deferring it a bit pending anything that comes
>>>>>> out of this thread.
>>>>>
>>>>> What would you like me to do? When do you think you could have
>>>>> 874 in?
>>>>>
>>>>
>>>> Probably by tomorrow. If there's going to be a CR2 I'd prefer you
>>>> don't delay CR1 for this. Getting things out in the wild is good,
>>>> the benefit of having this out in CR1 is outweighed by the benefit
>>>> of getting everything else in CR1 out in the wild sooner.
>>>>
>>>>>>
>>>>>>>>
>>>>>>>> 1) A bunch of the LinkedList fields in TransactionEntry are
>>>>>>>> protected. Changing them to LinkedHashSet therefore technically
>>>>>>>> changes the API. This is an internal class, so I don't think
>>>>>>>> that's an issue. Any objections?
>>>>>>>
>>>>>>> I'm ok with this, I don't think it will break the
>>>>>>> OptimisticTransactionEntry subclass. In fact, is there any
>>>>>>> reason why this needs to be protected? Could we make do with
>>>>>>> stronger access protection than protected?
>>>>>>>
>>>>>>
>>>>>> I don't see any reason why not; this is an internal class. I much
>>>>>> prefer private fields; hate protected 'cause it's never clear to
>>>>>> me if the class designer had a strong reason to expose them or
>>>>>> just did it "in case some subclass wants it some day". IMHO a
>>>>>> protected getter/setter with a private field is a much better
>>>>>> indication of design intent and allows clean subsequent addition
>>>>>> of things like lazy initialization.
>>>>>
>>>>> +1. And like I said, if we can make do with package-level access
>>>>> for the getter/setter and private for the field, I'd go with that
>>>>> if it makes sense.
>>>>>
>>>>
>>>> I'll check; we may not even need the getters/setters for this
>>>> particular case. I don't think the subclass uses any of the
>>>> protected fields. And if not, I don't think there is any real
>>>> "design intent" to expose them.
>>>> If later on, we find a real need to expose them, then we add them.
>>>>
>>>>>>
>>>>>>>>
>>>>>>>> 2) A number of TransactionEntry methods return List and
>>>>>>>> currently hand out a ref to the internal data structure. The
>>>>>>>> caller of these methods logically expects a List so I think
>>>>>>>> the API should remain the same. So, that implies the methods
>>>>>>>> would do something like "return new ArrayList(internalSet);"
>>>>>>>>
>>>>>>>
>>>>>>> Hmm, I guess so. Perhaps in 2.0.0, change this to return a
>>>>>>> Collection?
>>>>>>>
>>>>>>
>>>>>> Maybe. Depends on whether callers are relying on an expected
>>>>>> ordering. I had a quick look at these methods yesterday. At
>>>>>> least one is never invoked and thus can be dropped. For another,
>>>>>> at least in some cases, Set semantics are fine, so a possibility
>>>>>> for
>>>>>> 1.4.1 is
>>>>>> an added method that exposes the internal Set.
>>>>>
>>>>> Ok, I'm happy with this. Like you said, this *is* an internal
>>>>> class anyway.
>>>>>
>>>>
>>>> Yes. And if there is a path whereby outside code can access
>>>> this class (I think there is), adding methods doesn't break
>>>> any compatibility.
>>>>
>>>>>>
>>>>>> Another possibility for 2.0.0 is to return an Iterator over the
>>>>>> internal field, which would give the same ordering as a List
>>>>>> with no extra effort. I expect all the callers already end up
>>>>>> iterating over the List anyway.
>>>>>
>>>>> Is this the case? What about calling contains() on the List? I
>>>>> thought I saw this somewhere ...
>>>>
>>>> You did, but the contains() call is done internally to
>>>> TransactionEntry whenever any of the add methods are called
>>>> -- in order to ensure Set semantics on the internal lists.
>>>> Getting rid of this inefficiency is the primary benefit of
>>>> JBCACHE-874.
>>>>
>>>> - Brian
>>>>
>>>> _______________________________________________
>>>> jbosscache-dev mailing list
>>>> jbosscache-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
