XA transactions on a single CacheManager?
by Sanne Grinovero
Hi all,
I just noticed that when I'm making changes to multiple caches within
the same transaction, the transaction manager will treat this as XA
transactions.
That seems suboptimal as they are all managed by the same resource; is
there a configuration I'm missing or should I open a JIRA to ask for
an improvement?
I'm not just asking for performance reasons: having to setup a
transaction manager is an annoying configuration step for Java SE
users.
Thanks,
Sanne
10 years
Practical example of difficulties with dependencies
by Sanne Grinovero
Since we recently discussed the purpose of the "UberJar"s , I think it
would be a great exercise to look at this discussion:
- https://developer.jboss.org/message/953081
and ask ourselves what we could have done to make the first steps of
this new user less miserable.
Personally I think we could go a long way with some clear
documentation about our dependencies;
it's not hard to inject version properties from the pom files into the
docs, so we could have a little reminder about - for example - which
version of Hibernate is expected to have the JPACacheStore working.
Also, I think it's clear that uber jars - at least in this case - are
not even close to the solution, unless you intend to include all of
Hibernate ORM and transitive dependencies..
Thanks,
Sanne
10 years
ISPN embedded tutorial broken
by Vojtech Juranek
Hi,
I noticed that ISPN embedded tutorial (weather app) [1] is broken. It fails
with NPE when fetching weather information from OpenWeatherMap. It's broken as
OpenWeatherMap started to request user registration [2]. I checked couple of
other free weather service (like Weather underground, Yahoo Weather, World
weather online) and all of them seem to require some kind of user
registration.
Shall we register on OpenWeatherMap (I didn't investigate if API token can be
pushed to GitHub) or switch to RandomWeatherService as default service?
Thanks
Vojta
[1] http://infinispan.org/tutorials/embedded/
[2] http://openweathermap.org/faq#error401
10 years
Verifying Consistent Hash based routing using stats
by Galder Zamarreño
Hey Vittorio,
Expanding this to dev list in case anyone has interest. Latest commit is in [1]. The relevant code that verifies Consistent Hash (CH) based routing is in [2]. The way it works is this:
Assuming I have 3 nodes, A, B and C, with 2 as number of copies for distribution, I do the following:
0. Get stats from nodes A, B, C.
1. Generate a key K1 whose owners are A,B.
2. Generate a key K2 whose owners are B,C.
3. Generate a key K3 whose owners are C,A.
4. The primary node is always the first node of the owners, so if CH routing works fine, K1 would targeted for node A, K2 for node B and K3 for node C.
5. Call puts on keys K1, K2 and K3.
6. Get stats from nodes A, B, C.
7. For all nodes, "stores" value in latest stats should be +1 compared to initial stats. This would pass even if with a round-robin load balance policy.
8. For all nodes, "currentNumberOfEntries" value in latest stats should be (Number of copies) * ("stores"). This is the key assumption that guarantees CH routing works as expected.
^ To be more precise, this can only be guaranteed under certain circumstances: First, the ownership needs to be spread around, so a node does not take owner ship of 3 keys and another of only 1. We can guarantee that based on how we generate the keys. The second part is that if a put happens in a non-owner, this non-owner node will increase its "stores" values but not its "currentNumberOfEntries" since the key does not belong in this node. So, if any put request happened in a non-owner, there would be an inbalance in the ratio of currentNumberOfEntries to "stores".
Hope this helps.
Cheers,
[1] https://github.com/galderz/js-client/commit/c57c285561b73e67b7ebce04de67d...
[2] https://github.com/galderz/js-client/blob/t_steps/spec/infinispan_cluster...
--
Galder Zamarreño
Infinispan, Red Hat
> On 16 Mar 2016, at 08:25, Galder Zamarreño <galder(a)redhat.com> wrote:
>
> Hey,
>
> Sorry I missed your reply yesterday about the location of the code.
>
> I've not pushed my branch yet, I'll do that this morning. As soon as it's on Github I'll let you know :)
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
10 years
Uber jars - how do we want to use them
by Sebastian Laskawiec
Hey!
Uber jars have been around for quite a while but some old problems are
still biting our ankles. The biggest problem is JBoss Logging... But before
diving into the technical discussion, I would like to clarify how do we
treat Uber Jars and how other (let's call them "extra") modules should
integrate with them...
How Uber Jars look like:
- All Uber Jar dependencies are declared as:
- provided - those are APIs which should be available on your
container
- optional - all other dependencies
- compile - JTA (I'm not sure why, but probably because this is a
required API). I think it should be changed to provided at some point.
- Uber Jars have (almost) no dependencies (apart from JTA)
- Uber Jars contain everything to get a standard application running
with ISPN in a single jar
Now the biggest question is how to integrate other extra modules with them
- for example Spring or Cache Stores? Here are the options:
- Not integrate at all... users should use standard (small) jars in such
use cases
- This one has a big impact on our users, so I would assume no
- All extra modules should shade everything they need and provide their
own Uber Jars (like Spring Uber Jar = ISPN Core + Spring)
- This one might be really hard to maintain, so I would also vote for
no.
- All extra modules should integrate with small jars and Uber Jars (but
not both at the same time). An example application might want to add
Spring-embedded and Infinispan-embedded to it's classpath and it's ready to
go. Alternatively it could add Spring-embedded + infinispan-core + whatever
is needed. Adding both infinispan-embedded and infinispan-core is
prohibited.
- Easy for the users, a bit harder for us. My vote goes here.
Could you please share some thoughts whether this makes sense or not? Once
we achieve common understanding - I'll propose some technical solutions.
Thanks
Sebastian
10 years
Removal of auto-detection of indexed entities
by Sanne Grinovero
When booting Infinispan Server v. 8.2.0.Final I see this message being logged:
ISPN000403: No indexable classes were defined for this indexed cache;
switching to autodetection (support for autodetection will be removed
in Infinispan 9.0).
Does it mean we can finally remove the infamous, super-complex to
maintain and generally hated "feature" in Hibernate Search to
dynamically add new entities on the fly?
10 years
