Spring module - change dependencies to Uber Jars
by Sebastian Laskawiec
Hey!
I'm currently trying to solve a tricky class loading issue connected to
Spring, CDI and Uber Jars. Here's the scenario:
- Remote Uber Jar contains CDI module
- Our Hot Rod client use newer version of JBoss Logging which is present
in Wildfly/EAP modules
- However EAP and Wildfly will load (and make available for deployment)
their own version of JBoss Logging [1]
- The easiest fix for this is to relocate JBoss Logging package in
Uber Jar
- Spring module requires some classes from Infinispan Common and they in
turn need BasicLogger from JBoss Logging
- If we relocate JBoss Logging and will try to use Uber Jar with
Spring - we will end up with classloading issue [2]
So it seems the best approach is to make Spring depend on Uber Jars instead
of "small ones". Of course, users who use small jars will probably be
affected by this change (they would have to either accept using Uber Jars
or exclude them in their poms and add dependencies manually).
Is anyone against this solution? JIRA tracking ticket: [3].
Thanks
Sebastian
[1] Scenario with Weld enabled WAR
https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+fo...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
[3] https://issues.jboss.org/browse/ISPN-6132
8 years, 10 months
Multi tenancy support for Infinispan
by Sebastian Laskawiec
Dear Community,
Please have a look at the design of Multi tenancy support for Infinispan
[1]. I would be more than happy to get some feedback from you.
Highlights:
- The implementation will be based on a Router (which will be built
based on Netty)
- Multiple Hot Rod and REST servers will be attached to the router which
in turn will be attached to the endpoint
- The router will operate on a binary protocol when using Hot Rod
clients and path-based routing when using REST
- Memcached will be out of scope
- The router will support SSL+SNI
Thanks
Sebastian
[1]
https://github.com/infinispan/infinispan/wiki/Multi-tenancy-for-Hotrod-Se...
9 years
jdk8backported package
by Radim Vansa
Hi,
although we're on Java 8, there's still the package
org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
possibility) to remove these and use implementation provided by runtime?
Or have we tweaked them too much, so shall we rather rename them?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
9 years, 1 month
Sequential interceptors API
by Radim Vansa
Hi,
I would like to encourage you to play with the (relatively) new API for
sequential interceptors, and voice your comments - especially you corish
devs, and Galder who has much experience with async invocations and that
kind of stuff from JS-world.
I am now trying to use the asynchronous methods only (the
forkInvocationSync() is only temporary helper!); Dan has made it this
way as he wanted to avoid unnecessary allocations, and I welcome this
GC-awareness, but regrettably I find it rather hard to use, due to its
handler-style nature. For the simplest style interceptors (do this,
invoke next interceptor, and process result) it's fine, but when you
want to do something like:
visitFoo(cmd) {
Object x = null;
if (/* ... */) {
x = invoke(new OtherCommand());
}
invoke(new DifferentCommand(x));
Object retval = invoke(cmd);
return wrap(retval);
}
I find myself passing handlers deep down. There is allocation cost for
closures, so API that does not allocate CompletableFutures does not pay off.
I don't say that I could improve it (I have directed my comments to Dan
on IRC when I had something in particular), I just say that this is very
important API for further Infinispan development and everyone should pay
attention before it gets final.
So please, play with it, and show your opinion.
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
9 years, 2 months
Early Access builds of JDK 8u112 b01, JDK 9 b124 are available on java.net
by Rory O'Donnell
Hi Galder,
Early Access b124 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+120.html>.
Early Access b123 <https://jdk9.java.net/jigsaw/> (#5178) for JDK 9 with
Project Jigsaw is available on java.net, summary of changes are listed
here
<http://download.java.net/java/jigsaw/archive/123/binaries/jdk-9+123.html>
Early Access b01 <https://jdk8.java.net/download.html> for JDK 8u112 is
available on java.net.
Update to JEP 261 : Module System - email from Mark Reinhold [1]
- The special ALL-DEFAULT module name, which represents the default set
of root modules for use with the -addmods option [2];
- A more thorough explanation of how the built-in class loaders have
changed, how built-in modules are assigned to each loader,
and how these loaders work together to load classes [3]; and
- The reason why Java EE-related modules are no longer resolved by
default [4].
- There are various other minor corrections and clarifications, as can
be seen in the detailed diff [5].
Rgds,Rory
[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html
[2]http://openjdk.java.net/jeps/261#ALL-DEFAULT
[3]http://openjdk.java.net/jeps/261#Class-loaders
[4]http://openjdk.java.net/jeps/261#EE-modules
[5]http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html
<http://cr.openjdk.java.net/%7Emr/jigsaw/jeps/updates/261-2016-06-15.html>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
9 years, 3 months
Changing default Hot Rod client max retries
by Galder Zamarreño
Hi all,
Java Hot Rod client has 10 max retries as default. This sounds a bit too much, and as I find the need to add similar configuration to JS client, I'm wondering whether this should be reduce to 3 for all clients, including Java, C* and JS clients.
Any objections?
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
9 years, 3 months
Infispector
by Galder Zamarreño
Hi all,
I've just noticed [1], @Thomas, it appears this is your baby? Could you explain in more detail what you are trying to achieve with this? Do you have a video to show what exactly it does?
Also, who's [2]? Curious to know who's working on this stuff :)
The reason I'm interested in finding out a bit more about [1] is because we have several efforts in the distributed monitoring/tracing area and want to make sure we're not duplicating same effort.
1. Radim's Message Flow Tracer [3]: This is a project to tool for tracing messages and control flow in JGroups/Infinispan using Byteman.
2. Zipkin effort [4]: The idea behind is to have a way to have Infinispan cluster-wide tracing that uses Zipkin to capture and visualize where time is spent within Infinispan. This includes both JGroups and other components that could be time consuming, e.g. persistence. This will be main task for Infinispan 9. This effort will use a lot of interception points Radim has developed in [3] to tie together messages related to a request/tx around the cluster.
Does your effort fall within any of these spaces?
Cheers,
[1] https://github.com/infinispan/infispector
[2] https://github.com/mciz
[3] https://github.com/rvansa/message-flow-tracer
[4] https://issues.jboss.org/browse/ISPN-6346
--
Galder Zamarreño
Infinispan, Red Hat
9 years, 3 months
