AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Scott Marlow
Galder,
I'm trying to identify the right fix for addressing AS7-4007. I started
a clustered second level cache test that currently fails since
Infinispan isn't on the test application classpath.
The exception call stack that I'm getting is shown here
http://pastie.org/3503803.
I would like to discuss how we can address AS7-4007 (either on email or
IRC).
Initially, I worked around this by ensuring that the infinispan module
is available in the test application classpath
(https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fda...).
The hack was to export the Infinispan module when the Hibernate module
is brought into an application. This covered both JPA and Hibernate
native applications, however it exports into every other module that
references the Hibernate module (increasing the time that it takes to
link the Hibernate module into other modules). There are other problems
with requiring Infinipan to be in the application classpath (see
https://community.jboss.org/wiki/ModularSerialization).
I would like to better understand the alternatives (both short term and
long term) to address AS7-4007 and issues like it. Perhaps by using
MarshallingConfiguration.setClassResolver() to pass a
ModuleClassResolver to be used with Infinispan
marshalling/unmarshalling. Is that currently configurable with Infinispan?
Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a
few days ago (see http://pastie.org/3528553).
https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/jav...
contains the source for the ModularClassResolver class that David
referred to (as well as the ModularSerialization article linked above).
Scott
13 years, 9 months
Stuck on old configuration API
by Sanne Grinovero
Hi,
I'm confused on the new configuration API; while it's definitely an
improvement to understand the XML parsing, it seems functionality is
reduced too much.
Previously I could set the instance of an existing (already
instantiated) service, especially Transport and
TransactionManagerLookup which I need to override/reuse instances.
Now if I look into the .transport() section I see no setters at all,
unless I chain a *second* .transport() which reveals some unintended
public details [and looks awkward]:
cacheManager.getCacheManagerConfiguration().transport().transport().setConfiguration(
GlobalConfiguration gc );
but no way to override the instance.
Regarding the TransactionManagerLookup, I just realized that this is
the third rewrite of the whole configuration read/build and that it's
now living in flux between THREE generations in the same codebase,
with adapters from new, to fluent (2nd gen), to "legacy" which I
happen to still need as even using 2nd gen it delegates to it.
I had added a test to Infinispan core to make sure I would not end up
stuck on this, but all my tests are using the "old" 2nd generation API
from Infinispan 5.0 and were not migrated forward, so they didn't
highlight this problem.
I've secured a written authorization to shoot if someone attempts to
remove one of those deprecated methods.. sorry but now that 5.1 was
released it's too late to cleanup.
13 years, 10 months
configuration limitations
by Mircea Markus
Hi,
Here is config related problem and a suggested solution.
CloudTM's total order requires some new configuration attributes. These attributes should only be added to the new config hierarchy and not be present in the deprecated hierarchy.
The problem is that when we build a cache with the *new* configuration object, it is internally translated to the old configuration object and then passed to the cache. All our components use references to old-configs. This doesn't work is my scenario, as I don't want the old configuration to be aware of total order. I actually don't even want my new classes to depend on the old configuration, as it is deprecated.
The proper fix for this is to use new Configuration hierarchy internally but that's a massive change. So what I've done is to make the old configuration object hold a reference to the new configuration. This also helps making the new configuration available by @Inject. Any other suggestions?
Cheers
Mircea
--
Mircea Markus
twitter.com/mirceamarkus
Sr. Software Engineer, Infinispan
http://www.infinispan.org
13 years, 10 months
5.1.3?
by Manik Surtani
Guys - I see a few JIRAs being targeted at "5.1.x". Is there any urgency for a 5.1.3? Any critical fixes that would mandate a 5.1.3 release?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
13 years, 10 months
IncrementableEntryVersion
by Mircea Markus
Hi Manik,
We have a marker interface IncrementableEntryVersion that extends EntryVersion.
Are there use cases for having versions that are *not* increment-able?
Cheers,
Mircea
13 years, 10 months
An observation about total order and consistency
by Mircea Markus
With total order and sync replication it is possible for the following:
tm.begin()
cache(0).put(k,v);
tm.commit();
assert cache(0).get(k).equals(v); //always passes
assert cache(1).get(k).equals(v); //might fail!
//..but
eventually(cache(1).get(k).equals(v)) //this will always pass
In other words, after a transaction is completed, you are only guaranteed to see its results on the originator node. On replicas the value is only eventually made available.
Whilst this is fine for embedded caches, as in practice the replication would happen between different JVMs, this is still relevant for:
- hotrod: a client might tx-write on a node and read from the other
- tests
Cheers
Mircea
--
Mircea Markus
twitter.com/mirceamarkus
Sr. Software Engineer, Infinispan
http://www.infinispan.org
13 years, 10 months
