My weekly status update 12/15
by William Burns
Last week I submitted PRs for the following:
ISPN-5078
ISPN-5072
ISPN-4491
I also had to port 3 issues to product (conflict nightmare as usual)
I also have been working on
ISPN-4445
- It seems this one is a problem that a cache cannot be operated
upon when it is set to LAZY
initialization as everything seems to work fine if it is EAGER.
ISPN-4973
- I haven't been able to figure this one out yet, but will be
looking at it closer after 4445
I should be online in the afternoon EST.
- Will
10 years, 9 months
Clustered queries and custom indexes
by Jiri Holusa
Hi,
there is an interesting research around similarity search at my university driven by David Novák (CC-ed). If anyone interested, see [1][2][3].
Shortly: they basically achieved similarity search on any data (images, songs, etc...) by creating some sort of custom index, that stores a "similarity vector" for each object in the database. This index can solve queries like "give me the most similar images to this example". So why am I posting this here?
The architecture is designed on top of Infinispan and they want to use it to speed it up. Basically, they would like to distribute the entries across the cluster, each node would have the similarity index of its entries. Then, when a query comes, it would be distributed to all the nodes, custom search would be performed on the node's indexes and the result returned. This is approximately what Index.LOCAL and ClusteredQuery could do.
The difference is that the indexing and searching mechanism must be custom. So I wanted to ask what do you think about implementing such a feature to Infinispan. I was thinking about somehow extracting general API for indexing/searching, then e.g. our Lucene search would become its implementation.
I would be happy to take this as a contribution, since I find this extremely interesting topic and also create a diploma thesis out of this.
So here are some questions:
1) Is it doable?
2) Do we want this feature?
3) How to design it/where to start?
Any input is more then welcome :)
Cheers,
Jiri
[1] https://drive.google.com/file/d/0B4sztQSfpi3rRlJBQjJHMkR2LXc/view
[2] https://drive.google.com/file/d/0B4sztQSfpi3rU2p2MV9jRE9iTUk/view
[3] https://drive.google.com/file/d/0B4sztQSfpi3rZUpld24ydzJNclk/view
10 years, 9 months
Jgroups - One or more nodes have left exception while querying(get, replaceWithVersion) on the cache
by mohammedisaa.khan＠subex.com
Hi,
We are using the Infinispan 6.0.2 Final with hotrod client in our
application. We have 3 nodes and are running test with about 30 million
entries in the cache and about 300 million requests being processed.
During the Execution after a few hours, we get the following error -
1)Failed to recover cluster state after the current node became the
coordinator
2)org.infinispan.remoting.transport.jgroups.SuspectException: One or more
nodes have left the cluster while replicating command PrepareCommand
3) Message Send failed due to time out
4)Suspect Messages - although the nodes were active.
There were no crashes and all the nodes are active! But it seems like some
node appeared to leave the cluster(Deduced from error #2) and post that the
cluster misbehaves. Most requests return null for cache query although the
data is present in the nodes and the nodes are up and active. We have
written a debug script which individually queries the cache and the caches
respond, but when we run the hotrod client with all node Ip/ports. Only one
node seems to respond and other 2 nodes do not respond.
Could you tell me why errors 2,3 occur? Are these identified ? Have they
been fixed in 7.x?
This appears to break the system quite often. Kindly reach out with
solutions.
Regards,
Isaa
--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/Jgroups-One-or-more...
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
10 years, 9 months
JDK 9 images are now modular with JDK 9 Early Access build 41
by Rory O'Donnell
Hi Galder,
The initial changesets for JEP 220: Modular Run-Time Images [1] are
available
with JDK 9 early-access build 41 [2].
To summarize (please see the JEP for details):
- The "jre" subdirectory is no longer present in JDK images.
- The user-editable configuration files in the "lib" subdirectory
have been moved to the new "conf" directory.
- The endorsed-standards override mechanism has been removed.
- The extension mechanism has been removed.
- rt.jar, tools.jar, and dt.jar have been removed.
- A new URI scheme for naming stored modules, classes, and resources
has been defined.
- For tools that previously accessed rt.jar directly, a built-in NIO
file-system provider has been defined to provide access to the
class
and resource files within a run-time image.
More details are available at Mark Reinhold's latest blog entry [3]
Rgds, Rory
[1] http://openjdk.java.net/jeps/220
[2] https://jdk9.java.net/download/
[3] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 10 months
Infinispan Management Console project
by Tristan Tarrant
Hi all,
I have created a dedicated repository [1] for Infinispan Management
console on GitHub.
Since the project is built on pure HTML/Javascript/CSS using tooling
which is familiar in that world (NodeJS, Gulp, Bower, Angular, etc) it
makes sense for it to live by itself with its own release cycle.
The pom.xml file in there is not a mistake: releases will happen as jar
files pushed to JBoss's Nexus so that the main Infinispan project can
pull it in.
Contributions are welcome
Tristan
[1] https://github.com/infinispan/infinispan-management-console
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 10 months
ISPN000196: Failed to recover cluster state after the current node became the coordinator
by Periyasamy Palanisamy
Hi,
We are using Infinispan 5.3.0 version in Opendaylight based controller product in 2-node clustered environment. But when we tried to reboot a node in the cluster, the error "ISPN000196: Failed to recover cluster state after the current node became the coordinator" is thrown continuously which leads to cluster becomes unusable. I see there is a bug already raised in infinispan 5.3.0 (https://issues.jboss.org/browse/ISPN-3395), but there is no information on which version this issue got fixed.
Please confirm me on which infinispan version this issue is fixed.
Thanks,
Periyasamy
10 years, 10 months
JIRAs for a 7.0.3 release
by Erik Salter
Hi all,
I was asked to vote on a list of JIRAs for 7.0.3 and send it to the
mailing list. The next iteration of my application is migrating from
5.2.x to 7.0.x, so I'm really focused on hardening and stability,
especially WRT state transfer. Here are the ones I was looking at, mostly
related to state transfer:
- ISPN-5000
- ISPN-4949 (and related ISPN-5030)
- ISPN-4975
- ISPN-5027
Notes on a few others I was looking at:
- ISPN-4444, from the description, looks serious enough to include. I
haven't looked at the commit in-depth; appears to be limited to keys in L1?
- ISPN-4979 appears to be a substantial change. I would defer to the team
about how risky of a change it is.
And if ISPN-3561 makes it into a 7.0.3, I'd consider it a personal favor.
Regards,
Erik
10 years, 10 months
DeltaAware: different local/remote behaviour
by Radim Vansa
Hi,
I was trying to implement an effective atomic counters [1] in Infinispan
using the DeltaAware interface, but trying to use DeltaAware I've
spotted an unexpected behaviour; I wanted to have a Delta for
getAndIncrement() method, that would simply increment the value without
knowing the previous value ahead, and return this previous value.
Therefore, I was inserting a fake DeltaAware object into the cache that
generates this relative Delta.
This works as long as the originator != primary owner, as the delta is
generated during marshalling. However, if I store that object locally,
the fake object is not used to generate the delta and reapply it on
current instance in data container, but it is stored directly.
Is such difference in local/remote behaviour bug or feature? (this is
the main question in this mail)
It seems to me that there are two reasons to use deltas: reducing size
of RPCs and reduce their total number. So the design should optimize both.
I have another doubts about DeltaAware interface usefulness, tracked in
ISPN-5035 [2] - while it reduces bandwith from originator to primary
owner, the response from primary owner to originator carries the full
value. I also find quite inconvenient that only PutKeyValueCommand
somehow works with deltas, but ReplaceCommand does not.
I've also noticed that the backup carries the full value [3], not quite
a good idea when we're trying to reduce bandwith.
Generally, I think that EntryProcessor-like interface would be more
useful than DeltaAware.
Radim
[1] https://github.com/rvansa/infinispan/tree/t_objects
[2] https://issues.jboss.org/browse/ISPN-5035
[3] https://issues.jboss.org/browse/ISPN-5037
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years, 10 months
