trace vs log.isTraceEnabled
by Mircea Markus
Hi,
I'm not aware of any convention on using trace vs log.isTraceEnabled() to guard the trace statements.
if (trace) log.trace("some request related stuff")
vs
if (log.isTraceEnabled()) log.trace("some request related stuff");
The former is more efficient, but cannot be managed at runtime. It seems to be the preferred form, so shall we stick with it?
Cheers,
Mircea
14 years, 9 months
Testing ISPN 200
by Israel Lacerra
Guys,
I was thinking about test ISPN-200 in a real environment. I want to compare
the distributed queries with local queries in different scenarios. Do you
have any thought about this? Any suggestions?
My first idea is to create an application that puts and search "n" values
(of size "x") in a cache with "k" nodes...
What do you think about this?
thanks!
Israel
14 years, 10 months
ISPN-1384 - InboundInvocationHandlerImpl should wait for cache to be started? (not just defined)
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-1384
I've had a look to this and this race condition could, in theory, be resolved by making InboundInvocationHandlerImpl.handle() waiting for cache not only to be defined, but to be started. Otherwise there'll always be a potential race condition like the one showed in the log.
In this particular case, this is clustered get command being received from a clustered cache loader, which is arriving in the cache before this is started (and the cache loader has been created, hence the NPE).
Another question, is there any reason why CacheLoader is not a named cache component which can be initalised with a corresponding factory and to which other components can be injected (i.e. marshaller, cache...etc)?
In this particular case, this would also resolve the issue because ClusterCacheLoader.start() does nothing, so all the interceptor needs is a proper instance of ClusterCacheLoader available. The factory makes these available bejore inject.
Thoughts?
Cheers,
p.s. Dan, I am aware of https://issues.jboss.org/browse/ISPN-1324, maybe you're solving this indirectly with the work for that JIRA?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 10 months
Asymmetric caches and manual rehashing design
by Dan Berindei
Following the discussions last week I've written up a wiki page
describing the strategies for cache view management and state transfer
that will enable asymmetric caches and manual rehashing:
http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign
The state transfer part is not very detailed, as you'll see we want to
go with a non-blocking approach but I'm not sure we can finish that
for 5.1 so we're keeping a blocking fallback option.
Your comments are welcome, either on the list or on the wiki page.
Dan
14 years, 11 months
ISPN-ARQUILLIAN - embedded mode
by Martin Gencur
Hi,
I'm currently implementing support for testing of embedded caches in
https://github.com/mgencur/infinispan-arquillian-container project and
would like to discuss future steps.
As mentioned in http://community.jboss.org/message/551784, the tests
should look like this:
@RunWith(Arquillian.class)
class TestClass {
@InfinispanResource
DatagridManager datagridManager;
@Before
void setup() {
CacheContainer cm1 = ...
CacheContainer cm2 = ...
datagridManager.registerCacheManager(cm1, cm2);
}
@Test
void testMethod() {
datagridManager.cache(index).put(xx)
datagridManager.manager(index).getStatus()
datagridManager.tm(cache)...
...
}
}//TestClass
where the DatagridManager would be basically class with functionality of
MultipleCacheManagersTest class (org.infinispan.core.test package).
I would basically copy the following classes to the new project and do
some changes (removing all testng annotations etc.):
- AbstractCacheTest.java
- AbstractInfinispanTest.java
- MultipleCacheManagersTest.java (renamed to DatagridManager)
The project would depend on
infinispan-core-5.1.0.ALPHA2-tests.jar so all the other helper classes
(being used from those mentioned above) would be downloaded with this
jar.
This is because all these test classes are changing quite often so I'm
trying to copy the smallest possible number of classes and leave the
rest in infinispan-core. Later, when I want to update them, it will be
just a matter of changing of 2-3 classes.
What do you think about this approach?
Thanks for each reply
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
14 years, 11 months
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, 11 months
Long time no hear, or ISPN-78 continued
by Olaf Bergner
Hello,
it's been a while ... I'm the guy who a few months ago implemented
Infinispan's Spring support and started to work on ISPN-78 - Large
Object Support. Due to very personal reasons and a job change that
required my undivided attention that latter endeavour went into a
hiatus. Sorry for that.
Provided there's still interest in the community I'd like to continue
working on ISPN-78. But first let's see where we stand today. What
follows is in large part a reiteration of what was already said a few
months ago, but not all of us are blessed with an infallible memory.
At https://github.com/obergner/infinispan/tree/t_ispn78 you will find a
very simple solution based on the concept of a StreamingHandler, to be
obtained via Cache.getStreamingHandler():
public interface StreamingHandler<K> {
void writeToKey(K key, InputStream largeObject);
OutputStream writeToKey(K key);
InputStream readFromKey(K key);
boolean removeKey(K key);
StreamingHandler<K> withFlags(Flag... flags);
}
This solution basically works yet needs some love before it could be
left out into the wild. I think it's not too bad but in the interim I
have come to prefer a different solution I would like to start working
on, namely a dedicated StreamingCache that's completely separate from
the regular Cache.
Pros:
1. I think that it's highly unlikely that users would want store large
objects as well as "regular" objects within the same cache instance. In
my experience these two classes of objects are treated entirely
differently on the application level.
2. Moreover I *suspect* - though I know next to nothing about these
matters - that a user would have a hard time finding a set of tuning
parameters to satisfy the needs of both regular as well as large objects.
3. Keeping large object support as part of the regular cache *might*
entail that the same code paths would have to be optimized for both
regular as well as large objects. This *could* prove difficult in the
long term.
4. A separate StreamingCache would open up the possibility of defining
default settings tailored to the needs of large objects. Furthermore I
*suspect* that many cache settings would be irrelevant for large objects.
5. The semantics of regular and large object caches are sufficiently
different to warrant a clean separation. Large objects will very likely
not be replicated across different nodes, and I *suspect* that we will
have a hard time supporting full-blown transactions for them.
Cons:
1. Increased complexity.
2. Increased maintenance burden. Well, maybe. On the one hand, there's
one more kind of cache to take care of. On the other hand the regular
cache wouldn't have to pay attention to the streaming cache's needs.
3. Higher implementation effort ;-)
So my proposed course of action is:
1. Introduce a new interface StreamingCache that looks exactly like the
StreamingHandler above.
2. Rename StreamingHandlerImpl to StreamingCacheImpl.
3. Introduce a new concept, ChunkStore, a store for - you guessed it -
chunks.
4. Modify StreamingCacheImpl to delegate to ChunkStore instead of Cache.
5. And now for the fun part: create StreamingCacheConfiguration, a
basic, stripped down, bare bones, no frills variant of Configuration.
Whoa, that configuration code sure looks ... interesting. Could probably
need some pointers here.
6. Pray that I won't need a custom DataContainer and so forth.
What do you think? Does that make sense? Does it make basically sense,
yet you would suggest some improvements? Is it utter nonsense?
The current implementation basically works and entails minimal changes
to the existing code base. The proposed solution is not exactly rocket
science, yet considerably more work. So I'd like to make sure that I
don't head in the wrong direction.
Cheers,
Olaf
14 years, 11 months
Master not compiling
by Sanne Grinovero
Hi all,
the master branch is not compiling since the last commit "b6de38a",
but even before that it's not very clean: I'm seeing many branch
merges, history is an mess.
I'm going to recommend again to use Emmanuel's nice build script
https://gist.github.com/789588 which verifies you're actually testing
the commit and not depending on other state,
and to really avoid using the web interface only to do reviews and
handle pull requests.
I know that's adding a bit of a burden to the reviewer's time, but
that's why the original committer should polish his patch in a logical
sequence and add enough commit comments to ease the reviewer's work as
much as possible; otherwise it seems that more often the reviewer does
more work than the original developer, who is not even taking
responsibility for his code as someone else will check it.
I'm not angry :) just worried the discipline is getting a bit too low
for the very demanding standards we aim for and calling for some more
attention.
Sanne
14 years, 11 months
What should be the default transaction mode: transactional or non-transactional?
by Mircea Markus
Hi,
ATM the default cache transaction model in 5.1 is transactional. The main reason transactional cache was chosen by default was backward compatibility: existing code that access the cache in a mixed way (i.e. both transactional and non transactional) would fail if the default mode is non transactional. By fail I don't mean a runtime exception being thrown, but the the operations in transaction's scope being executed individually and the transaction ignored.
As Galder highlighted, the problem with being transactional by default is that you pay a penalti if you take Infinispan and run out of the box as a simple local cache for example. In theory, in only makes sense to enable transactional behaivour if you want transactions. [1]
Shall we switch to non-tx caches by default? Or implement ISPN-61 in 5.1, measure performance and if perf is ok stick with transactional cache? [2] Opinions?
Cheers,
Mircea
[1]
a). The performance for a get should be the same for a tx and non tx cache.
b) Put's performance is better now: 1RPC for non-tx and 2 RPC for tx. However this will change once https://issues.jboss.org/browse/ISPN-61. With ISPN-61 implemented, I expect the performance of both tx and non-tx caches to be roughly the same.
[2] Implementing first optimisation described in ISPN-61 is rather trivial right now.
14 years, 11 months
optimistic locking - the time has come
by Mircea Markus
Hi,
I've issued a pull request for SPN-1131 (Add support for optimistic locking).
My last run brought the same number of test failures in master and in my branch, so might be a good idea to integrate it first and then continue fixing tests.
Cheers,
Mircea
14 years, 11 months
