Jigsaw early-access builds updated (JDK 9 build 40)
by Rory O'Donnell
Hi Galder,
JDK 9 Early Access with Project Jigsaw build b40 is available for
download at :
https://jdk9.java.net/jigsaw/
The goal of Project Jigsaw [2] is to design and implement a standard module
system for the Java SE Platform, and to apply that system to the
Platform itself
and to the JDK.
The main change in this build is that it includes the jrt: file-system
provider,
so it now implements all of the changes described in JEP 220.
Please refer to Project Jigsaw's updated project pages [2] & [4] and Mark
Reinhold's update [5] for further details.
We are very interested in your experiences testing this build. Comments,
questions, and suggestions are welcome on the jigsaw-dev
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing list or
through bug reports via bugs.java.com <http://bugs.java.com/>.
Note: If you haven’t already subscribed to that mailing list then please do
so first, otherwise your message will be discarded as spam.
Rgds, Rory
[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
11 years, 4 months
Example of TUNNEL protocol
by Tuomas Kiviaho
Hi,
I'm trying to use TUNNEL protocol. JGroupsTransport seems to hang while
waiting forever because viewAccepted is never triggered. I can see from
JGossipRouter JMX that I've reached it, but it's unclear why there is no
VIEW_CHANGE response. Is there an example of using TUNNEL protocol with
Infinispan. I only found out about TCPGOSSIP but I've replaced it with
JDBC_PING.
I guess for clarity there should be some kind of await(timeout) instead of
await() and exception message could clarify the situation a bit for
beginners like me.
--
Tuomas
--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/Example-of-TUNNEL-p...
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
11 years, 4 months
Feature request: manage and share a CacheManager across deployments on WildFly
by Sanne Grinovero
I'm witnessing users of Hibernate Search who say they deploy several
dozens of JPA applications using Hibernate Search in a single
container, and when evaluating usage of Infnispan for index storage
they would like them all to share the CacheManager, rather than
starting a new CacheManager for each and then have to worry about
things like JGroups isolation or rather reuse via FORK.
This is easy to achieve by configuring the CacheManager in the WildFly
configuration, and then looking it up by JNDI name.. but is not easy
at all to achieve if you want to use the custom modules which we
deliver to allow using a different Infinispan version of what's
included in WildFly.
That's nasty, because we ultimately want people to use our modules and
leave the ones in WildFly for its internal usage.
It would be nice if the team could include in the modules.zip a way to
pre-start configured caches, and instructions to mark their
deployments as depending on this service. Would be useful to then
connect this to monitoring too..
Sanne
11 years, 4 months
Jigsaw early-access builds updated (build 38)
by Rory O'Donnell
Hi Galder,
JDK 9 Early Access with Project Jigsaw build b38 is available on
java.net [1]
The goal of Project Jigsaw [2] is to design and implement a standard module
system for the Java SE Platform, and to apply that system to the
Platform itself
and to the JDK.
The early-access builds implement the changes described in JEP 220 [3] .
The
jrt file-system provider is not yet implemented. As of build 38, the
extension
mechanism has been removed.
Please refer to Project Jigsaw's updated project pages [2] & [4] and
Mark Reinhold's
update [5] for further details.
We are very interested in your experiences testing this build. Comments,
questions,
and suggestions are welcome on the jigsaw-dev
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing list
or through bug reports
via bugs.java.com <http://bugs.java.com/>.
Note: If you haven’t already subscribed to that mailing list then please
do so first,
otherwise your message will be discarded as spam.
Rgds, Rory
[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/003946.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
11 years, 4 months
Schema versions
by Tristan Tarrant
Hi all,
I have issued a PR [1] which bumps the core parser and schema to 7.1,
since we're going to introduce schema changes there.
Do you think we should bump all schemas in sync (including the
cachestores) or shall we only do it when there are changes ?
Tristan
[1] https://github.com/infinispan/infinispan/pull/3069
11 years, 4 months
Remoting package refactor
by Pedro Ruivo
Hello,
As many of you should know, I'm refactoring the remoting package. I was
trying and testing what can be done and it's time for an update.
Finally, I got a working version (needs some cleanups) that can be found
here [1].
The goal is to reduce the complexity from CommandAwareRpcDispatcher and
InboundInvocationHandler. This classes are getting full of "if command
is type T, then do this" and it will get worse when ISPN-2849 [2] and
ISPN-4610 [3] is done. Also, it decouples the Transport from the
processing remote commands logic.
The main idea is to have one global inbound invocations handler and a
per cache inbound invocations handler. The first one will handle the
non-cache rpc commands and the later the cache rpc commands. Since each
cache has a different configuration, multiple per cache inbound
invocation handlers will be implemented. Currently, I have the non-total
order and a total order implementation. After ISPN-2849 and ISPN-4610,
I'll probably add more, for example: TO tx and TO non-tx, pessimistic,
optimistic and default non-tx implementations.
change details:
* remove total order remote executor service. The remote executor
service can be used and it has exactly the same goal.
* added a single thread remote executor service. This will handle the
FIFO deliver commands. Previously, they were handled by JGroups incoming
threads and with a new executor service, each cache can process their
own FIFO commands concurrently.
* currently the non-blocking cache rpc commands are processed directly
in JGroups threads. Not sure if it is ok, but I think we can add another
remote executor service for these commands. The advantage is that the
JGroups threads no longer will execute remote commands.
* the Transport is decoupled. May be useful for the test suite.
* possibly remove the TotalOrder*Command (TotalOrderPrepareCommand and
similar) (needs to double check). Since we have a total order inbound
invocation handler for total order transactions, it is not necessary a
special command to identify when the transaction is in total order or not.
Comments, ideas, feedback are welcome.
Cheers,
Pedro
[1] https://github.com/pruivo/infinispan/compare/remoting_refactor
[2] https://issues.jboss.org/browse/ISPN-2849 => don't keep thread
blocked waiting for locks
[3] https://issues.jboss.org/browse/ISPN-4610 => non transactional total
order
11 years, 4 months
