Proposal - encrypted cache
by Sebastian Laskawiec
Hey!
A while ago I stumbled upon [1]. The article talks about encrypting data
before they reach the server, so that the server doesn't know how to
decrypt it. This makes the data more secure.
The idea is definitely not new and I have been asked about something
similar several times during local JUGs meetups (in my area there are lots
of payments organizations who might be interested in this).
Of course, this can be easily done inside an app, so that it encrypts the
data and passes a byte …
[View More]array to the Hot Rod Client. I'm just thinking about
making it a bit easier and adding a default encryption/decryption mechanism
to the Hot Rod client.
What do you think? Does it make sense?
Thanks
Sebastian
[1] https://eprint.iacr.org/2016/920.pdf
[View Less]
6 years, 9 months
State transfer-related terms
by Radim Vansa
Hi,
I've started (again) working on ISPN-5021 [1], and I'd like to get some
common agreement on few terms. So below I summarize my understanding (or
misunderstanding) of these, please state you opinion, thinking a bit
more generally.
State transfer: whole process beginning with some ST-related event =
node being detected to crash/sending join or leave request, and ending
when this event is processed. When another event happens, the current ST
can either be finished or canceled and then *…
[View More]another* ST can begin.
State transfer is a cluster-wide process, though it cannot be started
and ended absolutely simultaneously.
Rebalance: one phase of ST, when the data transfer occurs.
Data rehash: this is a bit painful point: we have DataRehashEvent where
the name suggest that it is related rather to rebalance, but currently
it fires when CacheTopology.getPendingCH() == null (that means when ST
is complete), and the event itself also looks more like it should be
fired at the end of state transfer. If we have something more to do
after the rebalance, I am not sure how useful is firing that just
because all data has been transferred (but for example before old data
has been wiped out). Should I add another StateTransferEvent event (and
appropriate listeners)? That would break the compatibility with tightly
related implementations...
WDYT?
Radim
[1] https://issues.jboss.org/browse/ISPN-5021
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
[View Less]
8 years, 2 months
REPL async semantics in the context of Hibernate 2LC
by Galder Zamarreño
Hi all,
Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain:
I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode.
One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from …
[View More]the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async.
If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B.
However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay...
The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine.
However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1]
So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off?
Cheers,
[1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
--
Galder Zamarreño
Infinispan, Red Hat
[View Less]
8 years, 2 months
Lots of exceptions in tests
by Sebastian Laskawiec
Hey guys!
Just wanted to point out there we have lots and lots of error messages in
TC logs [1]:
[18:48:00] : [Step 2/5] org.infinispan.commons.CacheException:
java.lang.IllegalStateException: channel is not connected
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.rethrowAsCacheException(CommandAwareRpcDispatcher.java:134)
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(…
[View More]CommandAwareRpcDispatcher.java:128)
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:614)
Thanks,
Sebastian
[1]
http://ci.infinispan.org/viewLog.html?buildId=48357&buildTypeId=bt9&tab=b...
[View Less]
8 years, 2 months
Infinispan Managment Console versioning and releases
by Sebastian Laskawiec
Hey guys,
A while ago was been talking with Ryan and Tristan about automated releases
for Infinispan Management Console. I would like to send the main point for
wider audience.
Long story short, we were considering different versioning schemes, such as
X.Y.Z.SHA1 or using Z as an auto-increment counter for console releases.
The main problem we were trying to solve was how to release the management
console more often.
I would like to propose different approach - Let's stick with a standard
…
[View More]versioning (X.Y.Z.[Alpha|Beta|Fina] for releases and X.Y.Z-SNAPSHOT for
ongoing work). Then we need to embed SHA1 into the MANIFEST.MF to increase
tracability (in other words, here I have an Infinispan build and I need to
know which SHA1 was used to build the console). SNAPSHOTs will be pushed
into JBoss Repository [1] after each commit. Infinispan master branch will
have a SNAPSHOT dependency to the console. The tricky part are releases.
Well, at first we need to release the console (I hope we will automate that
in Team City). Then we can use the version plugin [2] to update the
Infinispan source code to the latest version of the console. Finally, we
can release the Infinispan. As a long-term goal, everything will happen
inside a single staging repository in Nexus (but that's a long-term goal...
first let get this running).
If you agree to my proposal, please change the version in the console into
9.0.0-SNAPSHOT and retrigger [3] (automated builds are disabled at the
moment). Next, I would kindly ask to look into the build logs [4][5] and
give me a hint how to fix it. The NPM plugin is failing with some weird
error. Once we are done with that, I will configure a Pull Request builder
and release job.
Thanks
Sebastian
[1] https://repository.jboss.org/nexus/content/repositories/snapshots/
[2] http://www.mojohaus.org/versions-maven-plugin/
[3]
http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_ManagmentCo...
[4]
http://ci.infinispan.org/viewLog.html?buildId=46542&buildTypeId=Infinispa...
[5]
http://ci.infinispan.org/viewLog.html?buildId=46543&buildTypeId=Infinispa...
[View Less]
8 years, 2 months
XSite route status listener in server - ISPN-7230/ISPN-7231
by Galder Zamarreño
Hi Paul,
Sorry to bother you again :)
Re: https://issues.jboss.org/browse/ISPN-7230 & https://issues.jboss.org/browse/ISPN-7231
The aim of these JIRAs is to have a x-site view exposed as an INFO message as well as JMX and DMR operation.
To do that, following Bela's advice, I've extracted RELAY2 protocol of the stack and on Infinispan's JGroupsTransport start() method, call setRouteStatusListener() with a relay RouteStatusListener implementation that allows the x-site view to be tracked […
[View More]1].
This works fine in library mode, but in server, on startup setRouteStatusListener() sometimes gets called after the Relayer's viewAccepted() method has been already called (which is the one that calls into RouteStatusListener). These means that the inital x-site view might not be registered.
So, what would be the correct place to add the setRouteStatusListener() call so that all views are captured? Or given how the server works, do I need to avoid using setRouteStatusListener() and use my own, Infinispan level, listener for tracking somehow?
Cheers,
[1] https://github.com/galderz/infinispan/blob/t_7230/core/src/main/java/org/...
--
Galder Zamarreño
Infinispan, Red Hat
[View Less]
8 years, 2 months
