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
7 years, 6 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...
7 years, 9 months
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
7 years, 10 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
8 years
Infinispan URL format
by Tristan Tarrant
In the past there has been talk of representing a connection to
Infinispan using a URL, in particular for HotRod.
The Hibernate OGM team is now working on adding NoSQL datasources to
WildFly, and they've asked for they should represent connections to
various of these.
For Hot Rod:
infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
currently support this, so this is forward-looking).
Obviously we will support all of the HotRod properties for specifying
things like security, etc.
For Embedded:
infinispan:embedded:file://path/to/config.xml (for specifying an
external config file)
infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
in JNDI)
infinispan:embedded: (configuration specified as properties)
For the latter, we also need to be able to represent an infinispan
configuration using properties with a simple mapping to XML
elements/attributes, e.g.
cache-manager.local-cache.mycache.eviction.size=1000
Comments are welcome
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years
Adding tests for new cache mode
by Radim Vansa
Hi,
I've decided to start working on Scattered Cache [1][2] POC. I'd like to
use most of the tests for distributed mode, but just extending
DistXxxTest with ScatteredXxxTest and overriding getCacheMode() seems
quite inelegant, though this is a common practice for repl/dist tests. I
had similar problem with Simple Cache, but I didn't need as many tests
for that.
@Parameters are not used as much in our testsuite - is there any reason
for that? And is there any better way, if I want just test everything
and exclude those tests where it does not make sense to run the test as
well?
Suggestions are welcome.
Radim
[1] https://issues.jboss.org/browse/ISPN-6645
[2] https://github.com/infinispan/infinispan/wiki/Scattered-Cache-design-doc
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
8 years
ClusteredGetCommand vs. SingleRpcCommand
by Radim Vansa
Just wondering, why do we have ClusteredGetCommand (and similar ones)
and don't wrap GetKeyValueCommand into SingleRpcCommand as with the
others? Git history starts in 2009, and I think this goes to real history :)
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
8 years, 1 month
Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net
by Rory O'Donnell
Hi Galder,
Early Access b118 <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+118.html>.
Early Access b118 <https://jdk9.java.net/jigsaw/> (#4913) for JDK 9 with
Project Jigsaw is available on java.net.
JDK 9 Build 118 includes a refresh of the module system.
There are several changes in this update, JDK 9 b118 has the updated
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on
the JDK 9 dev mailing list [2].
A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission from the default java.policy
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that
trusted code should be expected
to handle gracefully. The permission is no longer granted by default.
Rgds,Rory
[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
8 years, 1 month
