Returned mail: Data format error
by MAILER-DAEMON
The original message was received at Mon, 24 Dec 2018 19:45:21 +0800
from lists.jboss.org [170.234.174.38]
----- The following addresses had permanent fatal errors -----
<infinispan-dev(a)lists.jboss.org>
----- Transcript of session follows -----
while talking to lists.jboss.org.:
>>> MAIL From:"MAILER-DAEMON" <postmaster(a)lists.jboss.org>
<<< 501 "MAILER-DAEMON" <postmaster(a)lists.jboss.org>... Refused
7 years
Partial updates in 2LC
by Galder Zamarreno
Hey Radim,
We've had some chats in the past where we discussed the behaviour of non-tx
2LC and partial updates. I've wrote a couple of tests [1] to see how things
behave:
For a repl read-write, entity cache, if the failure happens on the async
FutureUpdate call, that's fine because the Tombstone has already been sent
and the cache won't return anything.
If the failure happens when the Tombstone is sent, we seem to have a
problem because it results in stale data in the node that failed to apply
the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply
because it doesn't find the Tombstone.
Sync logs any errors but does not propagate them [2]. Is there any reason
for not rethrowing the exception? I tried to rethrow it and the JDBC
transaction rolls back, which is not too bad cos at least that way both
nodes contain the last committed data.
As a side note, the CorrectnessTestCase subclasses are not running by
default, we should change that.
Cheers,
Galder
[1]
https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb...
[2]
https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/...
7 years
Single Port Client
by Sebastian Laskawiec
Hey guys,
During Infinispan F2F, I had a short discussion with Tristan on Single Port
client-side implementation. Back then, we agreed that the client should
always send a Hotrod Ping request and if won't get any response (or get
some HTTP content back), it will try to upgrade to the Hotrod protocol
using Single Port.
I've been playing with the implementation for a while, and implementing it
this way seems a bit "inconvenient" to me. The Ping Operation uses 60s
timeout, which seems to be a good fit as a default. Unfortunately, for the
Single Port functionality, this means we'd need to wait 60s until we try to
send HTTP request and do an upgrade. Also, another problematic part is in
Netty's HTTP handlers (HttpObjectDecoder, HttpServerCodec and
ByteToMessageDecoder). When those classes fail to decode a message (REST
expects HTTP rather than a stream of bytes specific to Hotrod protocol),
they just ignore it and keep the channel in active state (which also makes
sense for HTTP/1.1 and HTTP/2).
At this point, my intuition tells, that this doesn't look right and seems
to be a over-complicated. The whole HTTP upgrade idea seems to work the
other way around, use HTTP as a fallback and then upgrade to other
protocols. Forcing it to work a bit differently requires some more effort.
What if we preserved the Single Port setting in the client configuration
but implemented it as an enum with the following values - true/false/auto.
In automatic mode, the client would check if the server port is set to
8\d{1,3} (this covers 80, 8080, 8081, 8443 and friends). If that is true,
we'd try to follow HTTP Upgrade procedure. This looks very simple and I
think this might actually work. Please note, that we need the single port
setting in the client configuration to cover some corner cases like the
Single Port exposed on different port (like 4444) or Hot Rod exposed on
port that starts with 8.
What do you think about such simplification?
Thanks,
Sebastian
7 years
JDK 12 enters Rampdown Phase One
by Rory O'Donnell
Hi Galder,
*JDK 12 Early Access build **is now available **at : - jdk.java.net/12/*
* Per the JDK 12 schedule [1], we are now in Rampdown Phase One.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
o We’ve forked the main-line source repository, jdk/jdk, to the
JDK 12 stabilization repository.
Changes since the last availability email
* JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector
(Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*.
* JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved
to *Targeted*.
* JEP 344: Abortable Mixed Collections for G1
<http://openjdk.java.net/jeps/344> moved to *Targeted*.
* JEP 346: Promptly Return Unused Committed Memory from G1
<http://openjdk.java.net/jeps/346> to *Targeted*.
* JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326>
(Preview) *Proposed to drop from JDK 12*
o link to proposal on jdk-dev
<https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html>
Bug fixes reported by Open Source Projects :
o JDK-8211051 - fixed in b22 - reported by JUnit5
o JDK-8211422 - fixed in b23 - reported by Apache Batik
The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been
updated with the following target:
* With the 2019-04-16 CPU,
o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7
o Distrust TLS server certificates anchored by Symantec Root CAs.
Oracle Java SE 8 Release Updates [3]
* Public updates for Oracle Java SE 8 released after January 2019 will
not be available for business, commercial or production use without
a commercial license.
Rgds, Rory
[1] http://openjdk.java.net/projects/jdk/12/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html
[3] https://java.com/en/download/release_notice.jsp
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years
Obtaining cache via CDI on WildFly
by Gunnar Morling
Hey,
I was trying to configure and inject an Infinispan cache through CDI,
running on WildFly 14, using the Infinispan modules provided by the
server.
While I'm not sure whether that's something supported or recommended,
I found this preferable over adding Infinispan another time as part of
the deployment. I couldn't find any recent info on doing this (would
love any pointers, though), so here's my findings, in case it's
interesting for others:
* A jboss-deployment-structure.xml file is needed for adding the
dependencies to the modules org.infinispan and org.infinispan.commons
* Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
part of WF, so it must be added to the deployment
* The transitive dependency from infinispan-cdi-embedded to
org.infinispan:infinispan-commons must be excluded, otherwise linking
errors will occur
Perhaps a small example of this could be added to the Infinispan docs?
Btw. I also couldn't find an example for configuring a cache through
jboss-cli.sh, perhaps that's something to consider, too?
Cheers,
--Gunnar
7 years
