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, 9 months
Hot Rod encoding
by Galder Zamarreño
Hi all,
As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up.
The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set?
To be able to answer this question correctly, the Hot Rod client needs to know the type of the data.
Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream.
Protostream based marshaller adds encoding to the byte arrays by adding information of what the type of that is written, whether raw type or complex. Protostream is based around Protobuf which works well as medium for compatibility mode.
So, in essence, if we want get different clients working together, the simplest thing to do is to implement the Protostream marshaller in each client lang, and they should work together without probs.
This option has the downside that by limiting our compatibility marshalling to Protostream, how would a standard REST client would understand this format? They'd need to have a way to understand Protostream...
Another option would be to setlle on UTF-8 String as compatibility medium and get the languages to convert types into JSON UTF-8 String. I think this would work better for REST-based clients. Also, AFAIK protobuf objects can be transformed into JSON, so if there's already a protostream marshaller available, that can be used to transform to JSON.
Down the line we might want to add encoding to Hot Rod or switch to a technology where encoding is sorted out for us, e.g. HTTP-based protocols...
Thoughts?
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
8 years, 3 months
(Not-so-)optional cachestores
by Tristan Tarrant
Hi all,
Jakub has recently revived the Cassandra Cache Store (CCS from now on)
which, as you all will remember, was pushed to an external repository
where it lay in abandonment ever since.
We now need to add support for this store to Infinispan Server, but
unfortunately, because of the "monolithic schema" approach that WildFly
imposes on subsystems, this has to be done within the Infinispan
subsystem itself.
This creates a conundrum, since the CCS depends on Infinispan core,
server would depend on the CCS but server is part of the Infinispan build.
Possible solutions:
1) move the CCS back into the main repo
- pros: no more conundrum, built by default, easier to maintain
- cons: makes the repo even bigger, binds the lifecycle of the CCS
to Infinispan's
2) extend the server to be able to interpret the CCS schema but not
actually depend on its code and provide the code to instantiate the CCS
as an overlay module which can be installed on server
- pros: keeps the lifecycle of the CCS independent
- cons: additional complexity to handle the split, forces us to
still keep server aligned with schema changes in the CCS itself.
3) make the CCS a deployable cache store
- pros: easiest
- cons: not really ootb experience, no nice schema
4) create a dedicated subsystem for the CCS and "invent" a way to
reference it from the main Infinispan subsystem using a naming
convention, similar to how datasources are currently implemented.
- pros: keeps the two projects independent, reusable for other
Cachestores
- cons: writing a subsystem from scratch is complex (although bits
of it could be made reusable for multiple cachestores).
Your thoughts please.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years, 3 months
Infinispan Cache Store Failure Detection and Recovery
by Cosmin Stroe
Hello everyone,
We're setting up an Infinispan deployment for a web application. Our use
case includes a local Infinispan cache (running in the same JVM as the web
app) backed by a remote Infinispan cache (running in a separate JVM).
We have to investigate failure modes of said cache. One of the scenarios
we have to handle is "What happens if the remote Infinispan cache goes
away?". This could happen for various reasons, including if we restart the
remote Infinispan cache. We would like to have some known state during
remote cache outages (which we hope would happen very infrequently).
My conversation with "ttarrant" on Freenode led us to believe that
Infinispan doesn't currently have any failure mode handling built in, and
that it's possible that we could make the Async Store decorator optionally
be able to "resist" store failures. Not sure what other options we have.
The correct answer might also be, "Just have the cache return null if an
entry is not in the local cache and the remote cache is unresponsive, and
have the application gracefully handle the empty cache". I'm not sure if
that option can be implemented with the current Infinispan code.
Any thoughts on this?
Cosmin.
8 years, 4 months
Repeatable read nulls
by Radim Vansa
Hi,
in transactional mode with repeatable reads, the read entry is stored in
the context, even if it is null (iiuc). However, in
TxDistributionInterceptor.visitGetKeyValueCommand the valueIsMissing()
is checked which returns true if entry.isNull() (in RepeatableReadEntry
this is implemented as value == null). Therefore, null reads are not
repeatable.
Any reason for that?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
8 years, 4 months
Release schedule
by Tristan Tarrant
Hi all,
since the amount of pending PRs is quite large, I'm proposing we skip
Alpha releases for 8.2 and release a Beta at the end of January after
we've integrated them. Most of the PR are for internals only, so I don't
see this as a problem.
Wdyt ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years, 4 months
