Infinispan 5.3 and the new JGroups bundler
by Pedro Ruivo
Hi all,
In Infinispan 5.3 we are allowing message bundling due to "recent"
improvements made in JGroups' bundler.
The new bundler is the default in JGroups 3.3 but if you are using the
old bundler (UDP.bundler_type="old"), please may consider to change it
to use the new bundler (UDP.bundler_type="new").
If you don't want to change it, please consider that the old bundler can
lead a performance degradation in a low throughput system (when you have
1 or 2 threads performance operations). Note that, in the old blunder,
the messages are blocked until (default values, of course you can
tunning this values to match to your application):
* 30 milliseconds are expired;
or
* 64k bytes are ready to be sent.
Recall that this warning is valid for Infinispan 5.3 (and superior in
the future).
Thank You.
Regards,
Pedro Ruivo
11 years
Jira documentation component
by Tristan Tarrant
Hi all,
I've added a documentation component on Jira so that issues with
JavaDocs, WIKI, XSDs can be properly categorized.
Tristan
11 years
Re: [infinispan-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
by Galder Zamarreño
Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work.
Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated?
On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote:
> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context.
>
> Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere.
>
> I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this.
>
> Scott
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
11 years
FlagAffectedCommand interface hierarchy (ISPN-761)
by William Burns
While adding changes for cache methods (entrySet, keySet, values, size) to include passivated entries it had been pointed out to conditionally do these operations if flags such as SKIP_CACHE_STORE and SKIP_CACHE_LOAD were provided. Also does anyone have any feedback on if both flags should apply or just say SKIP_CACHE_STORE? Currently SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand do not inherit from FlagAffectedCommand which are used for commands that behavior is dependent upon flags.
The problem is that FlagAffectedCommand currently extends VisitableCommand, TopologyAffectedCommand, MetadataAwareCommand interfaces. These interfaces do not really apply to the commands I am working on as they are local only. I was planning on removing the extended interfaces from the FlagAffectedCommand interface and update all the commands that implement this interface currently to make sure they still properly implement the additional interfaces. Searching for instanceof FlagAffectedCommand it also appears that all current references should be alright after refactoring. Once these interfaces are decoupled I can add the FlagAffectedCommand interface to the SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand and subsequently to the CommandFactory and my changes should be good.
Any opinions or concerns?
Thanks,
- Will
11 years
