Configuration visitor - Re: [JBoss JIRA] Commented: (ISPN-145) No transport and singleton store enabled should not be allowed
by Vladimir Blagojevic
Hi,
Galder and I talked about this offline. Time to involve you guys!
I just completed visitor pattern for our configuration objects. Visitor
is passed from root of configuration - InfinispanConfiguration object.
InfinispanConfiguration class has a new method:
public void accept(ConfigurationBeanVisitor v)
How do we want to integrate this visitor into existing structure?
1) We add a new factory method to InfinispanConfiguration with
additional ConfigurationBeanVisitor parameter
2) We leave everything as is and if there is a need to pass some visitor
we pass it to InfinispanConfiguration instance directly (from
DefaultCacheManager)
DefaultCacheManager will pass ValidationVisitor to
InfinispanConfiguration that will verify configuration semantically.
Regards,
Vladimir
On 09-09-09 10:19 AM, Galder Zamarreno wrote:
> Good idea :)
>
> On 09/09/2009 04:13 PM, Vladimir Blagojevic wrote:
>> Yeah,
>>
>> I was thinking that we can make a visitor for configuration tree and
>> then you can do verification of any node and other things as well. Use
>> cases will come up in the future for sure.
>>
>> Cheers
>>
>>
>>
>> On 09-09-09 3:29 AM, Galder Zamarreno (JIRA) wrote:
>>> [
>>> https://jira.jboss.org/jira/browse/ISPN-145?page=com.atlassian.jira.plugi...
>>>
>>> ]
>>>
>>> Galder Zamarreno commented on ISPN-145:
>>> ---------------------------------------
>>>
>>> Not sure I understand what you mean by generic though. You mean any
>>> component to have a validation step of some sort?
>>>
>>> Thanks for taking this on :)
>>>
>>>> No transport and singleton store enabled should not be allowed
>>>> --------------------------------------------------------------
>>>>
>>>> Key: ISPN-145
>>>> URL: https://jira.jboss.org/jira/browse/ISPN-145
>>>> Project: Infinispan
>>>> Issue Type: Bug
>>>> Components: Loaders and Stores
>>>> Affects Versions: 4.0.0.ALPHA6
>>>> Reporter: Galder Zamarreno
>>>> Assignee: Vladimir Blagojevic
>>>> Priority: Minor
>>>> Fix For: 4.0.0.CR1
>>>>
>>>>
>>>> Throw configuration exception if singleton store configured without
>>>> transport having been configured.
>>>> It makes no sense to have singleton store enabled when there's no
>>>> transport.
>>
>
14 years, 4 months
Using Coverity scan?
by Sanne Grinovero
Hello,
Did you consider enabling Infinispan to be monitored by coverity's
code analysis services? They are free for OSS projects, I saw a demo
recently and was quite amazed. It's similar to FindBugs, but not only
about static code checks. They checkout your code from trunk and then
run several analysis on it periodically, one of them is about dynamic
thread behavior to predict deadlocks or missing fences instrumenting
the code, and produce nice public reports; AFAIK you don't need to
setup anything yourself, besides getting in touch to ask for it.
It's only available for C and Java code, and they have an impressive
list of OSS projects in the C world (linux kernel, httpd server,
samba, gnome, GCC, PostgreSQL, ...) but not much on Java.
http://scan.coverity.com/
No, I'm not affiliated :-) Just thinking that it might be useful to
have if it's not too hard to setup.
Cheers,
Sanne
15 years, 1 month
Hot Rod - pt3
by Galder Zamarreno
Hi all,
Re: http://community.jboss.org/wiki/HotRodProtocol
First, I've made the corresponding changes based on the feedback I got
from pt2. This included reducing the response header since clients are
already aware of what they sent, addition of topology view id to to non
dumb requests and further specification in responses when topology
changes have happened...etc.
I've also added flags to the request header that allow sending
Infinispan flags like: skip cache store, zero lock acquisition
timeout...etc.
Note that I've noted this as being N * 1 byte where each byte represents
a flag. However, I think this could maybe be sent more efficiently by
using XOR, i.e.
0x00 -> no flag
0x01 (0000 0001) -> zero lock acquisition
0x02 (0000 0010) -> cache mode local
0x03 (0000 0011) -> zero lock acquisition + cache mode local
0x04 (0000 0100) -> skip locking
...etc.
With 2 bytes, we could implement 16 Flags, we currently 11. However, we
could use vint as well, making sure that the most significant bit does
not mean anything flag wise. Iow, with vint, in 1 byte we'd be able to
define 7 diff flags. Thoughts?
I've also added the quit command that disconnects clients.
Finally, as far as I'm concerned, the specification is complete. I'm
leaving the quiet commands out of this initial scope (see
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol).
Remember that quiet commands could be used so that the server buffers
responses and only when you send a non-quiet command, the server replies
with all the pending answers.
As you can see at the bottom of the wiki, I've added a local only put
request/response example so that readers get an idea of what a full
command looks like. I had received some feedback from readers saying
that it was difficult to understand how it all fit together.
I'll probably add a couple more examples for non-so-dumb and clever
request/responses but I'll held them until we have a final round of
feedback and people can indicate whether they want any other examples
appearing in the wiki.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 11 months
Lock amortization preliminary performance numbers
by Vladimir Blagojevic
Hi all,
As you probably recall I am working on a LIRS eviction algorithm. But before we get there, Manik and I agreed that I push in a direction of implementing ConcurrentHashMap(CHM) variant that will do lock amortization and eviction per segment of CHM. So far I have implemented LRU eviction so we can verify feasibility of this approach rather than eviction algorithm itself. We are hoping that eviction algorithm precision will not suffer if we do eviction per segment and you all are familiar with lock striping benefits of segments in CHM.
So, I've cobbled up a first test to compare eviction and lock amortized enabled CHM (BCHM) with regular CHM and synchronized HashMap. The test is actually based on already existing test [1] used to measure performance of various DataContainers. I've changed it slightly to measure Map directly instead of DataContainer. The test launches in cohort 48 reader, 4 writer and 1 remover threads. All operations are randomized; readers execute map.get(R.nextInt(NUM_KEYS), writers map.put(R.nextInt(NUM_KEYS), "value"), and finally removers execute map.remove(R.nextInt(NUM_KEYS). NUM_KEYS was set to 10K. Each thread does in a loop 1K ops.
Initial capacity for CHM and HashMap were set to 1K, max capacity for eviction and lock amortized enabled CHM was set to 256; therefore BCHM has to do a lot of evictions which is evident in map final size listed below.
Size = 9999
Performance for container ConcurrentHashMap
Average get ops/ms 338
Average put ops/ms 87
Average remove ops/ms 171
Size = 193
Performance for container BufferedConcurrentHashMap
Average get ops/ms 322
Average put ops/ms 32
Average remove ops/ms 74
Size = 8340
Performance for container SynchronizedMap
Average get ops/ms 67
Average put ops/ms 45
Average remove ops/ms 63
If I remove lock amortization for BufferedConcurrentHashMap, that is if we attempt eviction on every get/put/remove, performance of put/remove for BCHM goes to zero basically! As far as I can interpret these results, BCHM get operation performance does not suffer at all in comparison with CHM as it does for single lock HashMap. Predictably, for single lock HashMap each type of operation takes on avg almost the same amount of time. We pay a hit in BCHM put/remove operations in comparison with CHM but the numbers are promising, I think. If you have comments, or even suggestions on how to test these map variants in a different, possibly more insightful approach, speak up!
Cheers,
Vladimir
[1] http://fisheye.jboss.org/browse/~raw,r=1264/Infinispan/trunk/core/src/tes...
16 years
JPA Cache Store
by Amin Abbaspour
Hi All,
I know that most of you are already busy fixing the remaining issues
toward first GA release, but I would like to open a small topic here
that may be affective for next major release (4.1.0 or so).
As subject shows, I would like to add a JPA compatible cache store to
Infinispan. I feel that current available cache stores are designed
with this concept that store is just a place for cache persistence and
initialization and do not much consider store as a major logical part
of the system. While to use Infinispan as a write-behind in front of a
previously defined structured RDBMS we need a general purpose
structural cache store.
I myself have conceptual problems with JPA (and in general any sort of
ORM) but yet I believe here is one of the rare cases where ORM is the
best tool around. We can easily use all the progress in the field of
OR mapping without considering much how it works in fact.
As a result less people (like I myself) will need to extends
CacheStores to create their own custom store. (although this will
always remain open for those who like)
You accept that, this store will not only increase our competitiveness
with available commercial products (which already have this feature)
but will also open the door for a feasible 'Infinispan DB' which will
make it also a player in IMDB market.
Thoughts?
Regards,
Amin
16 years
Marshalled Value issue
by Galder Zamarreno
On 01/28/2010 09:35 AM, Galder Zamarreno wrote:
>
> One quick note about marshalled values. Over the past few days, I've
> been fighting a random failure in a concurrent test in the 2nd level
> cache. I still haven't got to the bottom of it, but I've narrowed it
> down to something related to marshalled values cos when it's switched
> off, the test always passes.
>
> My gut feeling is that there's some thread safety issue with marshalled
> values but still can't pin point the exact issue.
>
> I'll keep you posted but I'm not sure I'll be able to resolve it in the
> next couple of days before I go on holidays.
To make sure everyone understands the complexity of this, logging for
marshalled values is a bit of a mess. The same marshalled object can be
represented in 3 diff ways in the logs:
MarshalledValue(cachedHashCode=0; serialized=false)
-> This is shown when the marshalled value that has not yet been
deserialized at all. The main issue here is:
+ On one side, when the MarshalledValue is created from MVI, we should
comnpute it's hashcode. This is hardly any cost for us cos we have the
Object instance and we don't have to do any deserialization.
A side issue here is that two different objects could have the same
hashcode, so simply showing that might not be good enough to
differentiate them in the logs. So, we need to add identity hash code
information at the end of the toString representation. To give you an
example of this:
Here's a key for collection cache:
org.hibernate.test.cache.infinispan.functional.Customer.contacts#3
Here's a key for entity cache:
org.hibernate.test.cache.infinispan.functional.Customer#3
These two produce the same MarshalledValue representation:
MarshalledValue(cachedHashCode=3; serialized=false)
Now, the other two representations:
MarshalledValue(cachedHashCode=3; serialized=false)
-> This is shown when the MarshalledValue has been deserialized. Here
the hashcode is 3, which comes from CacheKey's hashCode which is
represented by the primary key.
org.hibernate.test.cache.infinispan.functional.Customer.contacts#3
-> This is the toString() representation of CacheKey.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Asymmetric logging for lock aquisition attempt and success/failure
by Galder Zamarreno
Hi,
I'm trying to track down an elusive random bug and I've noticed that in
LockManagerImpl, we print:
if (trace) log.trace("Attempting to lock {0} with acquisition
timeout of {1} millis", key, lockTimeout);
But whether this succeeded or not is logged in clients of lockAndRecord,
i.e. EntryFactoryImpl:
if (lockManager.lockAndRecord(key, ctx)) {
// successfully locked!
if (trace) log.trace("Successfully acquired lock!");
return true;
It'd be better if the success/failure was logged in LockManagerImpl, so
that you can simply enable TRACE on LockManagerImpl, rather than having
to do that in that class and also in any client class calling
lockAndRecord().
If anyone has any objections to moving "Successfully acquired lock!" to
LockManagerImpl, let me know.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Obtaining TransactionManager in an Easy Way
by Amin Abbaspour
Hi All,
Why there is no easy way to get TransactionManager from
(Advanced)Cache? I can see that you do reflection in
TestingUtil.getTransactionManager in order to get TM. BTW TestingUtil
is in test and not available unless one builds custom jars.
Regards,
Amin Abbaspour
16 years
Versions of jbossts
by Sanne Grinovero
Hello,
until some weeks ago Infinispan was using this dependency:
<dependency>
<groupId>jboss.jbossts</groupId>
<artifactId>jbossjts</artifactId>
<version>4.6.1.GA</version>
</dependency>
and this was then updated to version 4.9.0.GA for some other problem,
but this version is failing when using the Lucene Directory Demo which
needs a JBossStandaloneJTAManagerLookup.
I need to at least restore the old version on the demo only, but would
prefer Infinispan could recommend a consistent version.
Isn't this 4.9.0.GA version giving problems to other tests?
going to open a thread on jboss-ts forums, I can't CC the userlist as
mailman is down and I'm not subscribed to that list.
Regards,
Sanne
16 years
