Infinispan embedded off-heap cache
by yavuz gokirmak
Hi all,
Is it possible to use infinispan as embedded off-heap cache.
As I understood it is not implemented yet.
If this is the case, we are planning to put effort for off-heap embedded
cache development.
I really need to hear your advices,
best regards
11 years, 10 months
Design change in Infinispan Query
by Sanne Grinovero
Hello all,
currently Infinispan Query is an interceptor registering on the
specific Cache instance which has indexing enabled; one such
interceptor is doing all what it needs to do in the sole scope of the
cache it was registered in.
If you enable indexing - for example - on 3 different caches, there
will be 3 different Hibernate Search engines started in background,
and they are all unaware of each other.
After some design discussions with Ales for CapeDwarf, but also
calling attention on something that bothered me since some time, I'd
evaluate the option to have a single Hibernate Search Engine
registered in the CacheManager, and have it shared across indexed
caches.
Current design limitations:
A- If they are all configured to use the same base directory to
store indexes, and happen to have same-named indexes, they'll share
the index without being aware of each other. This is going to break
unless the user configures some tricky parameters, and even so
performance won't be great: instances will lock each other out, or at
best write in alternate turns.
B- The search engine isn't particularly "heavy", still it would be
nice to share some components and internal services.
C- Configuration details which need some care - like injecting a
JGroups channel for clustering - needs to be done right isolating each
instance (so large parts of configuration would be quite similar but
not totally equal)
D- Incoming messages into a JGroups Receiver need to be routed not
only among indexes, but also among Engine instances. This prevents
Query to reuse code from Hibernate Search.
Problems with a unified Hibernate Search Engine:
1#- Isolation of types / indexes. If the same indexed class is
stored in different (indexed) caches, they'll share the same index. Is
it a problem? I'm tempted to consider this a good thing, but wonder if
it would surprise some users. Would you expect that?
2#- configuration format overhaul: indexing options won't be set on
the cache section but in the global section. I'm looking forward to
use the schema extensions anyway to provide a better configuration
experience than the current <properties />.
3#- Assuming 1# is fine, when a search hit is found I'd need to be
able to figure out from which cache the value should be loaded.
3#A we could have the cache name encoded in the index, as part
of the identifier: {PK,cacheName}
3#B we actually shard the index, keeping a physically separate
index per cache. This would mean searching on the joint index view but
extracting hits from specific indexes to keep track of "which index"..
I think we can do that but it's definitely tricky.
It's likely easier to keep indexed values from different caches in
different indexes. that would mean to reject #1 and mess with the user
defined index name, to add for example the cache name to the user
defined string.
Any comment?
Cheers,
Sanne
11 years, 11 months
code highlight in github/asciidoc
by Mircea Markus
Github's wiki asciidoc doesn't play nicely with syntax highlighting: displays all the code with the same plain color, instead of highlighting the syntax elements like the IDEs do.
E.g. the sample code provided in the wiki asciidoc help:
.python.py
[source,python]
----
# i just wrote a comment in python
print "something"
# and maybe one more
----
renders like:
http://screencast.com/t/k6JVQrWQ4
Whilst the markdown equivalent:
```python
# i just wrote a comment in python
print "something"
# and maybe one more
```
renders as expected:
http://screencast.com/t/YLMhs31Jm
I think this has been a problem for quite a while now: https://github.com/gollum/gollum/issues/280
Does anyone see any problem with allowing both markdown and asciidoc editors for our wiki? They both have pretty basic syntax and markdown seems to be better integrated (I guess that's why it's also the default editor).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years, 3 months
Improve WriteCommand processing code and [possibly] performance
by Pedro Ruivo
Hi guys.
I've open a JIRA to tack this: https://issues.jboss.org/browse/ISPN-3664
Suggestions/feedback is appreciated. This is probably be integrated in
the next major (but no promises).
I was not cleared just ping me.
Have a nice weekend folks :)
Regards,
Pedro
Description is the following:
Major refactorization of the write command with the following goals:
* Base WriteCommand: all the write command has the same workflow through
the interceptor chain
* Create a concrete WriteCommand for each operation (put, remove,
replace, replaceIfEquals, removeIfEquals, putIfAbsent)
* Extend the interceptor chain to process each one of the command and
add a new "visitWriteCommand", that is invoked by the default visitX
methods.
* (minor) change the GetKeyValueCommand to ReadCommand to make name
"compatible" with WriteCommand.
Note that most of the interceptor only needs to implement the
visitWriteCommand because all the write command has the same execution
flow. The basic flow of the write commands are: (non-tx) lock, fetch
value (cachestore/remote), check condition and apply change. for tx
mode, lock (if pessimistic), fetch value (cache loader, remote, etc),
apply change and add it to the transaction (if successful)
Also, another advantage is the simplification of the EntryFactory
because if we think a little about it, independent of the write command
we need to wrap the entry anyway.
Suggested implementation
class abstract WriteCommand,
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if
(match(entry.getValue()) then entry.setValue(newValue);
entry.setChanged(true); entry.setRemoved(newValue == null)}
* Concrete implementations *
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return
!flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare *
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no
different implementation needed.
12 years, 3 months
CS API still needs more polishing?
by Galder Zamarreño
Hi,
Doing this throws a warning due to unchecked assignment:
ExternalStore<Integer, String> boundedStore = new SingleFileStore();
Granted, the users won't be doing this, but should all cache stores use generics properly? At the end of the day, implementations such as SingleFileStore are what cache store developers are gonna be looking at to get inspiration of how to write cache stores.
I'm aware that some of the internals assume Object keys and values, and there will be a point where an unchecked cast will need to be done, but this should happen within the internals of our cache implementation.
Cache store implementations should use generics properly.
Cheers,
p.s. Or maybe we should move to language were generics are properly enforced ;)
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12 years, 3 months
Fwd: [hibernate-dev] Thinking about Forge 2 plugins
by Sanne Grinovero
as described below, it would be nice to update the Infinispan forge
plugin to use Forge 2?
---------- Forwarded message ----------
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
Date: 24 October 2013 11:24
Subject: [hibernate-dev] Thinking about Forge 2 plugins
To: Hibernate Dev <hibernate-dev(a)lists.jboss.org>
We probably should think about what it would mean to help people get
started with our projects using Forge. The Eclipse integration looks
very impressive and very much how I wish I could work to add layers.
I'll add it to the team meeting agenda.
Emmanuel
Date: Mon, 21 Oct 2013 18:27:12 -0400 (EDT)
From: Lincoln Baxter <lbaxter(a)redhat.com>
To: The Core
Subject: The Forge 2 philosophy in 4 minutes
Check out the video describing Forge 2 and where we are headed:
http://www.youtube.com/watch?v=Dpou-FWWatI
Just a quick update on the Forge project. This video will show you
what we've been working on for the past while: namely a new
architecture to allow extreme embed-ability, and real code re-use
between addons (using our Modular container, called Furnace)
https://github.com/forge/furnace (based on JBoss Modules and Maven).
It does not go into great detail into many of these things, but is
more of a high-level overview of the goals and features.
So what does this mean for your project?
1) Primarily, this means that you'll be able to work with us to
create tools for your project that run in all of our supported
environments and IDEs. Ideally this tooling should be focused on
getting users started with your projects quickly, so if you're
interested in having a Forge plugin for your project, please send me
an email off list, and we will get the process started. We are
currently preparing for the launch of our new website, so it will
probably still be a few months before we can do any intensive project
addon development with teams.
2) What this means in reality is that you can deliver tools that will
run in JBDS and the command-line (and eventually IntelliJ, and
NetBeans, and Web IDE), without worrying about coordination with an
actual product release. Your release cycle is completely independent
of ours. (Unless you are waiting for a new feature that is not yet
released.)
To learn more about Forge 2, please visit our github repository:
https://github.com/forge/core#jboss-forge-20
Expect to hear more from us soon :) We want *YOU*... and your projects
of course :)
--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter(a)redhat.com
"If you want something, you'll find a way; if you don't, you'll find an excuse."
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12 years, 3 months
JSR-107 and invalidation cache
by Balázs Zsoldos
Hi,
a couple of months ago I tested the new JSR-107 functionality of
Infinispan. Distribution and replication cache worked fine, however, I had
problems with invalidation cache type. If I called cache.put() or
cache.update() the entries were deleted from other nodes. In my
understanding if I call cache.update() the entries on other nodes should be
deleted but they should be left there if I call cache.put() on a new node.
Am I wrong? Did you check this use-case?
I opened a question on stackoverflow at
http://stackoverflow.com/questions/16465807/jcache-api-usage-with-invalid...
nobody answered.
I also opened a question in the Infinispan forum at
https://community.jboss.org/thread/228039 but nobody answered.
Is JSR-107 functionality specified anywhere in case of using invalidation
cache? Distributed cache is great, however, in case of read-intensive large
data sets I think invalidation cache type cannot be avoided due to
performance reasons.
Thanks and regards,
Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34
Everit Kft.
https://www.everit.biz
Everit OpenSource
http://everit.org
12 years, 3 months
