Notifier - performance optimization
by Mircea Markus
Hi,
There is place for some performance optimization with respect to the
notification mechanism, in the Notifier class:
1) there are defensive Maps being created for being passed in the
pre/post notifications, even if no listeners are registered.
2) even if we do not have listeners for a certain event, there is still
a lookup in the listeners map to check for the available list of listeners
Optimizations:
for 1) - do not trigger a notification if no listener registered, use a
guard - similar to log.isTraceEnabled()
for 2) - rather than keeping a map with listeners registered for each
annotation type, rather keep the listeners list as a member - this way
we'll skip the list lookup.
Another thing that just come into my mind is not iterating on the list
of listeners but rather use sequential access - small gain though.
I expect this would gain us some performance, especially in the
standalone mode.
WDYT?
Cheers,
Mircea
15 years, 11 months
Cutting 2.2.0.CR1
by Manik Surtani
Folks,
I'm gonna cut 2.2.0.CR1 as soon as I have the newly raised
JBCACHE-1349 resolved. I expect this would be around midday (GMT)
tomorrow (Monday). Any reasons for me to hold this back? Mircea?
Cheers
Manik
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
15 years, 11 months
Handling invalid nodes
by Manik Surtani
Guys,
I've been thinking about behaviour with the Node API, and wonder what
works best from a user standpoint. Consider:
* User gets a hold of a node and holds on to the ref for performance
reasons (Node n = cache.getNode(fqn))
* Performs tasks on the node: n.put(), n.get(), etc.
* Node checks for validity before performing any API calls, throwing a
NodeNotValidException if the node is not valid anymore.
Nodes get marked as invalid if they are removed or moved by a
concurrent thread, or invalidated by a remote one. Eviction did not
mark a node as invalid, but I think this is inconsistent and a bug:
eviction too should mark the node as invalid.
So the question is this - with potentially likely events marking a
node as invalid - especially with eviction - should we throw a
NodeNotValidException? Since (as of 2.1.0), the Node implementation
that a user has is an instance of NodeInvocationDelegate which in turn
has a reference to an UnversionedNode, perhaps we should handle the
NNVE within the NodeInvocationDelegate and perform a lookup internally
and refresh the UnversionedNode reference, and THEN throw a NNVE if we
can't fetch the node?
Th drawback is that this is potentially two calls for what should be
one - node gets evicted, we call cache.getNode() internally to refresh
the reference (from a cache loader, etc), and then invoke whatever
call the user intended to call up the interceptor chain. The benefit
is a smoother user experience.
Thoughts/opinions?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
15 years, 11 months
Re: [jbosscache-dev] jboss-javaee.jar shipped with JBC
by Brian Stansberry
Dimitris, what's the status on releasing JBoss javaee 1.1.0.GA?
Scott Stark wrote:
> I didn't say it was incompatible. We needed consistent lgpl licenses and
> the sun code used to be non-redistributable. So either track down the
> current license and implications or use the jboss version.
>
> Manik Surtani wrote:
>> So if JBoss AS can't ship jta-1.1.jar because of license
>> incompatibilities, then neither could JBC.
>>
>> Interestingly, Hibernate Core, also LGPL, ships with jta-1.1.jar.
>>
>>
>>
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
15 years, 11 months
Re: [jbosscache-dev] jboss-javaee.jar shipped with JBC
by Manik Surtani
So if JBoss AS can't ship jta-1.1.jar because of license
incompatibilities, then neither could JBC.
Interestingly, Hibernate Core, also LGPL, ships with jta-1.1.jar.
On 15 May 2008, at 16:58, Scott Stark wrote:
> Its just licensing differences and source availability (at least
> historically). Ours is lgpl, sun's should be dual cddl/proprietary,
> but that would have to be validated.
>
> Dimitris Andreadis wrote:
>> Regarding the javaee apis, I believe there is a licensing issue,
>> whether we ship the Sun provided libraries or ours (the content
>> should be the same).
>>
>> Scott?
>>
>> Brian Stansberry wrote:
>>> No, not sure what that one is; looks like something official from
>>> Sun given its pom [1]. Seems the one I'm talking about is only a
>>> CR1: http://repository.jboss.org/maven2/org/jboss/javaee/jboss-transaction-api...
>>>
>>> Dimitris -- do you see any advantage in JBC integrating the
>>> org.jboss.javaee/jboss-transaction-api.jar vs this javax/
>>> transaction/jta-1.1.jar? AFAICT, seems like both just contain JTA
>>> 1.1 version of the javax.transaction packages. (Why do we produce
>>> our own if Sun already produces one?) The AS is going to integrate
>>> the full org.jboss.javaee/jboss-javaee.jar so either way there's
>>> going to be a trivial maven dependency mismatch so we'll just
>>> exclude the JBC dependency in the AS pom.
>>>
>>> [1] http://repository.jboss.org/maven2/javax/transaction/jta/1.1/jta-1.1.pom
>>>
>>> Manik Surtani wrote:
>>>> I'm guessing that's jta-1.1.jar?
>>>>
>>>> On 15 May 2008, at 15:27, Brian Stansberry wrote:
>>>>
>>>>> The jboss-javaee project has recently been refactored so that
>>>>> jar is now an assembly of a set of jars for each of the specs
>>>>> that comprise JEE; there should be a jta-only component jar as
>>>>> well. I'll find it for you.
>>>>>
>>>>> Manik Surtani wrote:
>>>>>> Guys,
>>>>>> The only reason we ship jboss-javaee.jar with JBC is for the
>>>>>> JTA interfaces. jboss-javaee.jar, however, brings along with
>>>>>> it whole bunch of excess baggage, which (1) makes the distro
>>>>>> unnecessarily large, and (2) causes problems in some
>>>>>> environments [1].
>>>>>> Can anyone see anything wrong with dropping jboss-javaee.jar
>>>>>> and replacing it with jta-1.1.jar [2]? I'm guessing we'd need
>>>>>> to make sure this is marked as optional in Maven, so it can be
>>>>>> excluded from projects that get deployed in an EE environment
>>>>>> (or any other environment where JTA is provided).
>>>>>> Thoughts?
>>>>>> Manik
>>>>>> [1] http://jira.jboss.org/jira/browse/JBCACHE-1347
>>>>>> [2] http://repository.jboss.org/maven2/javax/transaction/jta/1.1/
>>>>>> --
>>>>>> Manik Surtani
>>>>>> Lead, JBoss Cache
>>>>>> manik(a)jboss.org
>>>>>> _______________________________________________
>>>>>> jbosscache-dev mailing list
>>>>>> jbosscache-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Lead, AS Clustering
>>>>> JBoss, a division of Red Hat
>>>>> brian.stansberry(a)redhat.com
>>>>
>>>> --
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> manik(a)jboss.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
15 years, 11 months
jboss-javaee.jar shipped with JBC
by Manik Surtani
Guys,
The only reason we ship jboss-javaee.jar with JBC is for the JTA
interfaces. jboss-javaee.jar, however, brings along with it whole
bunch of excess baggage, which (1) makes the distro unnecessarily
large, and (2) causes problems in some environments [1].
Can anyone see anything wrong with dropping jboss-javaee.jar and
replacing it with jta-1.1.jar [2]? I'm guessing we'd need to make
sure this is marked as optional in Maven, so it can be excluded from
projects that get deployed in an EE environment (or any other
environment where JTA is provided).
Thoughts?
Manik
[1] http://jira.jboss.org/jira/browse/JBCACHE-1347
[2] http://repository.jboss.org/maven2/javax/transaction/jta/1.1/
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
15 years, 11 months
[JBCACHE-1342] Lack of lifecycle methods in CacheLoaderConfig classes
by Galder Zamarreno
Hi all,
Re: http://jira.jboss.com/jira/browse/JBCACHE-1342
I've converted JDBCCacheLoaderConfig into a JavaBean class, however I
have some lifecycle issues now. setProperties() method within it, as
well as setting individual fields, also creates composite fields such
as: insertNodeSql, selectChildNamesSql...etc
If we want to create JDBCCacheLoaderConfig beans via individual
properties, rather than the setProperties() method we need some kind of
create step where we know that properties have already been set, and we
can use the create step to create the sql queries.
The bigger problem I suppose is that from what I can see setProperties()
is only really called after parsing the XML configuration, but this does
not happen for AS, as the configuration is parsed by the MC. I can see
quite a few bugs arising from this area, iow untested configurations. In
fact, I just came across another one:
http://jira.jboss.com/jira/browse/JBCACHE-1346
The JBossCache wikis are not available at the moment and I'm not sure
whether lifecycle annotations are explained somewhere else, so that we
can integrate the cache loader configurations into the cache lifecycle.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years, 11 months
Updated maven scripts
by Manik Surtani
I've updated a few things in the maven scripts we use:
1. The support-common POM now takes in certain properties which can
be defined in child POMs, to determine behaviour. Defaults are
provided in the support-common POM, so default behaviour won't change
from what you are used to.
1.1. "defaultTestGroup", which defaults to "functional" - the
default TestNG group for Surefire to run
1.2. "javadocPhase", the default phase in which to generate
javadocs. Defaults to "package".
2. The JBoss Cache core POM has changed, such that:
2.1. "mvn package" no longer generates javadocs and user guides,
etc. This now *only* compiles, tests and generates a jar file.
2.2. Skip tests above by doing "mvn package -Dmaven.test.skip=true"
2.3. Javadocs are now generated when you do a "mvn install".
2.4. Generate docs by specifying the "Docs" profile, in any phase.
E.g., "mvn package -P Docs" will be exactly the same as "mvn package"
prior to this change.
2.5. Changed the way you specify which test groups to run. No
longer a system property (-Dgroups=functional) but now using profiles
(-P test-functional). (The sys properties tripped up the javadoc
plugin!!)
2.6. Default test group run is now "unit" and not "functional". Run
functional tests by doing "mvn test -P test-functional".
See README-Maven.txt in jbosscache-core for more details.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
15 years, 11 months
