Why no use async listener executor?
by Galder Zamarreño
Hey guys,
Re: https://issues.jboss.org/browse/ISPN-1396
While looking into this, I've discovered that we have been creating executors in cache level components, where we're calling submit from @Listener implementations.
For example, BaseStateTransferManagerImpl.ViewChangeListener submits a rehash task and TransactionTable.StaleTransactionCleanup submits a tasks to break locks.
Did the people that wrote these listeners (Dan & Mircea respectively) consider defining listeners to be called asynchronously? i.e. @Listener(sync = false)
Unless you have very strict requirements, the async listener executor should just work, and would lead to reuse of executors which results in lower consumption.
The same applies to the singleton store executor btw.
Surely, if we were to expand on to other use cases, async notification executor should have more than 1 max thread by default, otherwise we could easily hold up tasks.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 7 months
FineGrainedAtomicMap preview
by Vladimir Blagojevic
Hey guys,
I about to integrate FineGrainedAtomicMap into master but before I do I
need your feedback. I particularly need feedback from users who where
eagerly awaiting this feature (Sanne and others) and possibly their
use/test cases of how they intended to use FineGrainedAtomicMap so we
can integrate these use/test casesinto the test suite.
I created a separate interface FineGrainedAtomicMap to distinguish it
from AtomicMap. Yes, of course, if you declared a variable of type Map
one could still assign both AtomicMap and FineGrainedAtomicMap to the
same variable but this way we force users to distinguish them at least a
bit. There is a separate factory method in AtomicLookup for
FineGrainedAtomicMap. The best way to see how this works is to look at
the test cases at
https://github.com/vblagoje/infinispan/commit/a4d107c6783ee7db6bd1bec35b8...
Mircea, I need your help regarding concurrent tx and
FineGrainedAtomicMap. Have a look at
FineGrainedAtomicMapAPITest#testConcurrentTx(the above link) as it is
failing if I do *not* run two threads sequentially, i.e. there is a
sleep of 2 sec to prevent concurrent tx running. Any ideas why is this
happening? The test failed in the old locking architecture as well. In
the old architecture, an entry was not wrapped with MVCCEntry because we
do not look up (and lock) AtomicHashMap but we issues
"synthetic/composite" lock requests for keys in that AtomicHashMap. If
we look up and lock key for AtomicHashMap the the whole point of
FineGrainedMap is lost as we would lock entire map. I noticed that
AtomicHashMap was being wrapped with ImmortalEntry. Maybe this is why
changes are not seen with concurrent tx, but how is it that the changes
are seen if tx are not run concurrently? If you could demystify this for
me I'd be grateful.
The commit is here
https://github.com/vblagoje/infinispan/commit/a4d107c6783ee7db6bd1bec35b8...
Regards,
Vladimir
12 years, 7 months
AS7's Infinispan subsystem custom classes
by Tristan Tarrant
Hi everybody,
I've been thinking about what would be the best way for users to provide
their own custom classes to be used by caches built by AS7's Infinispan
subsystem.
There are two ways: as modules or as deployments.
I don't really like the modules approach as it requires users to then
add the module as a dependency of the Infinispan subsystem, and I would
like that to stay untouched.
I've been playing instead with the deployment approach, borrowing code
from the JCA/JDBC layer within AS7 which allows JDBC drivers to be
deployed by using the standard Java services interface (i.e. via
META-INF/services/com.example.ServiceInterface). Using this method,
users just drop a JAR with their implementation in
standalone/deployments (or the equivalent domain method), add the
necessary bits to META-INF/services/* and META-INF/MANIFEST.MF (for
importing the org.infinispan classes), and the deployer picks them up
and makes them available as an AS7 service. The classes can then be
referenced in the Infinispan subsystem definition.
For bits that don't have interfaces (e.g. Listeners) but are defined via
annotations, AS7 provides equivalent support.
Paul, I would very much like your opinion on this, and especially on any
bits I might have overlooked.
Tristan
12 years, 7 months
Re: [infinispan-dev] [jboss-as7-dev] Serializing Data in the Modular World
by Galder Zamarreño
Interesting article Jason.
This might be handy for Infinispan because in the discussions we had in Lisbon, we're talking about being able to have the module identifier included in the payload for AS envs. Your solution would make our lifes easier.
Couple of questions:
- Is ModularClassResolver a class of JBoss Marshalling or AS?
- What happens if you use ModularClassResolver in a non-AS environment? Could it delegate to a backup class resolver? I think this could be useful.
Cheers,
On Sep 27, 2011, at 11:03 PM, Jason T. Greene wrote:
> Hi Everyone,
>
> I wrote up an article today that talks about the issues (and solutions)
> of serializing in a modular (or any multi-classloader) environment:
>
> http://community.jboss.org/wiki/ModularSerialization
>
> If you are developing any kind of component that sends data on AS7, then
> please give this a read.
>
> As an example of the application of this information, ejb3 remote
> communication is being developed to follow solution 3.
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 7 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
12 years, 7 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
12 years, 7 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.
>>
>
12 years, 7 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
12 years, 7 months
