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
Atomic operations and transactions
by Sanne Grinovero
Hello all,
some team members had a meeting yesterday, one of the discussed
subjects was about using atomic operations (putIfAbsent, etc..).
Mircea just summarised it in the following proposal:
The atomic operations, as defined by the ConcurrentHashMap, don't fit
well within the scope of optimistic transaction: this is because there
is a discrepancy between the value returned by the operation and the
value and the fact that the operation is applied or not:
E.g. putIfAbsent(k, v) might return true as there's no entry for k in
the scope of the current transaction, but in fact there might be a
value committed by another transaction, hidden by the fact we're
running in repeatable read mode.
Later on, at prepare time when the same operation is applied on the
node that actually holds k, it might not succeed as another
transaction has updated k in between, but the return value of the
method was already evaluated long before this point.
In order to solve this problem, if an atomic operations happens within
the scope of a transaction, Infinispan eagerly acquires a lock on the
remote node. This locks is held for the entire duration of the
transaction, and is an expensive lock as it involves an RPC. If
keeping the lock remotely for potentially long time represents a
problem, the user can suspend the running transaction and run the
atomic operation out of transaction's scope, then resume the
transaction.
In addition to this, would would you think about adding a flag to
these methods which acts as suspending the transaction just before and
resuming it right after? I don't know what is the cost of suspending &
resuming a transaction, but such a flag could optionally be optimized
in future by just ignoring the current transaction instead of really
suspending it, or apply other clever tricks we might come across.
I also think that we should discuss if such a behaviour should not be
the default - anybody using an atomic operation is going to make some
assumptions which are clearly incompatible with the transaction, so
I'm wondering what is the path here to "least surprise" for default
invocation.
Regards,
Sanne
14 years, 2 months
DataContainer performance review
by Vladimir Blagojevic
Hi,
I would like to review recent DataContainer performance claims and I was
wondering if any of you have some spare cycles to help me out.
I've added a test[1] to MapStressTest that measures and contrasts single
node Cache performance to synchronized HashMap, ConcurrentHashMap and
BCHM variants.
Performance for container BoundedConcurrentHashMap (LIRS)
Average get ops/ms 1063
Average put ops/ms 101
Average remove ops/ms 421
Size = 480
Performance for container BoundedConcurrentHashMap (LRU)
Average get ops/ms 976
Average put ops/ms 306
Average remove ops/ms 521
Size = 463
Performance for container CacheImpl
Average get ops/ms 94
Average put ops/ms 61
Average remove ops/ms 65
Size = 453
Performance for container ConcurrentHashMap
Average get ops/ms 484
Average put ops/ms 326
Average remove ops/ms 376
Size = 49870
Performance for container SynchronizedMap
Average get ops/ms 96
Average put ops/ms 85
Average remove ops/ms 96
Size = 49935
I ran MapStressTest on my Macbook Air, 32 threads continually doing
get/put/remove ops. Fore more details see[1]. If my measurements are
correct Cache instance seems to be capable of about ~220 ops per
millisecond on my crappy hardware setup. As you can see performance of
the entire cache structure does not seem to be much worse from a
SynchronizedMap which is great in one hand but also leaves us some room
for potential improvement since concurrent hashmap and BCHM seem to be
substantially faster. I have not tested impact of having a cache store
for passivation and I will do that tomorrow/next week.
Any comments/ideas going forward?
[1] https://github.com/infinispan/infinispan/pull/404
14 years, 3 months
Alert from a failing test
by Sanne Grinovero
Hello all,
I'm not in state to fully debug the issue this week, but even though
this failure happens in the Lucene Directory it looks like it's
reporting an issue with Infinispan core:
https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/90/org...
In this test we're writing to the index, and then asserting on the
expected state on both nodes, but while it is successful on the same
node as the writer, it fails with
"java.io.IOException: Read past EOF" on the second node.
This exception can mean only one thing: the value, which is a
buffer[], was not completely transferred to the second node, which
seems quite critical as the caches are using sync.
I can't reproduce the error locally, but it's not the first time it is
reported by CI: builds 60, 62, 65 for example (and more) show the same
testcase fail in the same manner.
Cheers,
Sanne
14 years, 3 months
some thoughts on mutual dependencies in Query/Search
by Sanne Grinovero
While reviewing ISPN-200 it's clear that Israel needed to copy over
some code from Hibernate Search in Infinispan Query, to make some
small changes to internal classes; All the changes I spotted so far
are around making some objects serializable.
I don't want to keep these copies around, especially as we're talking
about very core and complex classes as
org.hibernate.search.query.engine.impl.HSQueryImpl, which is not going
to be maintainable in a forked situation, and definitely not meant for
consumption by other projects.
So I have some options:
1) I change the HSQueryImpl in Search to make it serializable, porting
Israel's patches "upstream".
2) Create an externalizer in Infinispan Query which knows about the
internals of HSQueryImpl
Clearly the Externalizer solution is highly coupled to the specific
version of Search, so that might become another issue in maintaining
them aligned, and this is not the appropriate class to be bound to a
"serialization contract", but is also the recommended way according to
Infinispan's spirit (compared to make it Serializable).
We could add a submodule in Hibernate Search to specifically test that
the Query module is not going to break, but this is going to create a
dangerous embrace in the release cycles of the two projects.
I'm starting to wonder if Query shouldn't live in the Hibernate Search
repository: it's highly coupled to Search, but nicely decoupled from
Infinispan as it depends on it's public API (so still subject to be
broken by changes in Infinispan, but that would be considered a bug in
Infinispan).
It is of course possible to polish the Search APIs more to make sure
that it's also nicely decoupled from it, but it's harder to achieve;
specifically by the very recurrent need to serialize/marshal it's
objects, or specific Lucene classes. Hibernate Search has always been
compatible with a specific version of Lucene only, as this API is in
continous flux too, so one of the goals of the project is to "shield"
users from the breaking changes which are often introduced; to be
conidered as well: most classes in Lucene are not serializable, or
even if they are it's a deprecated feature and the maintainers are not
interested in keeping wire compatibility.
of course in the short term it's easy to make those classes
serializable, or not even needed just defining an externalizer. So I
think we should start with one of these while this complex
contribution takes shape, but also consider options for near-future.
opinions?
Cheers,
Sanne
14 years, 3 months
benchmarking transactions
by Mircea Markus
Hey guys,
These are some preliminary figures from transaction benchmarking. The weird thing is that performance fro a transactional put is much better (5-10 times) than for a non transactional one. Even if I set the syncCommitPhase to true that still stands.
Each transaction only spreads over one write.
Config used: http://bit.ly/k59giN
I'll try to give it a try locally and let you know about the findings.
14 years, 3 months
