Where's the roadmap?
by Sanne Grinovero
I was asked about the Infinispan roadmap on a forum post, my draft reads:
"Sure it's available online, see.."
but then I could actually only find this:
https://community.jboss.org/wiki/InfinispanRoadmap
(which is very outdated).
So, what's the roadmap?
Would be nice if we could have it updated and published on the new website.
Cheers,
Sanne
11 years, 7 months
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, 11 months
Re: [infinispan-dev] Design change in Infinispan Query
by Mircea Markus
On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> Sure searching for any cache is useful. What I was advocating is that if you search for more than one cache transparently, then you probably need to CRUD for more than one cache transparently as well. And this is not being discussed.
Not sure what you mean by CRUD over multiple caches? ATM one can run a TX over multiple caches, but I think there's something else you have in mind :-)
>
> I have to admit that having to add a cache name to the stored elements of the index documents makes me a bit sad.
sad because of the increased index size?
> I was already unhappy when I had to do it for class names. Renaming a cache will be a heavy operation too.
> Sanne, if we know that we don't share the semi index for different caches, can we avoid the need to store the cache name in each document?
>
> BTW, this discussion should be in the open.
+1
>
> On 31 janv. 2014, at 18:04, Adrian Nistor <anistor(a)gmail.com> wrote:
>
>> I think it conceptually makes sense to have one entity type per cache but this should be a good practice rather than an enforced constraint. It would be a bit late and difficult to add such a constraint now.
>>
>> The design change we are talking about is being able to search across caches. That can easily be implemented regardless of this. We can move the SearchManager from Cache scope to CacheManager scope. Indexes are bound to types not to caches anyway, so same-type entities from multiple caches can end up in the same index, we just need to store an extra hidden field: the name of the originating cache. This move would also allow us to share some lucene/hsearch resources.
>>
>> We can easily continue to support Search.getSearchManager(cache) so old api usages continue to work. This would return a delegating/decorating SearchManager that creates queries that are automatically restricted to the scope of the given cache.
>>
>> Piece of cake? :)
>>
>>
>>
>> On Thu, Jan 30, 2014 at 9:56 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>> curious to see your thoughts on this: it is a recurring topic and will affects the way we design things in future in a significant way.
>> E.g. if we think (recommend) that a distinct cache should be used for each entity, then we'll need querying to work between caches. Also some cache stores can be built along these lines (e.g. for the JPA cache store we only need it to support a single entity type).
>>
>> Begin forwarded message:
>>
>> > On Jan 30, 2014, at 9:42 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
>> >
>> >>
>> >> On Jan 21, 2014, at 11:52 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>> >>
>> >>>
>> >>> On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>> >>>
>> >>>> By the way, people looking for that feature are also asking for a unified Cache API accessing these several caches right? Otherwise I am not fully understanding why they ask for a unified query.
>> >>>> Do you have written detailed use cases somewhere for me to better understand what is really requested?
>> >>>
>> >>> IMO from a user perspective, being able to run queries spreading several caches makes the programming simplifies the programming model: each cache corresponding to a single entity type, with potentially different configuration.
>> >>
>> >> Not sure if it simplifies things TBH if the configuration is the same. IMO, it just adds clutter.
>> >
>> > Not sure I follow: having a cache that contains both Cars and Persons sound more cluttering to me. I think it's cumbersome to write any kind of querying with an heterogenous cache, e.g. Map/Reduce tasks that need to count all the green Cars would need to be aware of Persons and ignore them. Not only it is harder to write, but discourages code reuse and makes it hard to maintain (if you'll add Pets in the same cache in future you need to update the M/R code as well). And of course there are also different cache-based configuration options that are not immediately obvious (at design time) but will be in the future (there are more Persons than Cars, they live longer/expiry etc): mixing everything together in the same cache from the begging is a design decision that might bite you in the future.
>> >
>> > The way I see it - and very curious to see your opinion on this - following an database analogy, the CacheManager corresponds to an Database and the Cache to a Table. Hence my thought that queries spreading multiple caches are both useful and needed (same as query spreading over multiple tables).
>> >
>> >
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11 years, 11 months
Musings on ISPN/JGRPs OSI transport choices and ambitions
by cotton-ben
Hi Mircea, Manik, Bela, et. al.
I want to more publicly muse on this SUBJ line. Here now, then maybe in
ISPN /user/ forum, then maybe JSR-347 provider wide. I know we had a
semi-private (Bela led) exchange, but I want to be more public with this
conversation.
Long post again. sorry.
This is just on open musing. I realize this musing should not expect to be
accommodated by any "oh, we got to do this in ISPN/JGRPs now!" repsonse ...
there is absolutely only the most infrequent use-case that would /today/ be
served by addressing this musing ... but tomorrow that /will/ be a different
story.
Questions::
Does the concept of ISPN/JGRPs transport between "Cluster" nodes currently
depend on OSI transport layer sockets' participation(s)?
In other words, if all the nodes on my "Cluster" have locality=127.0.0.1 is
ISPN/JGRPs accommodating enough to use a native OS IPC choice as an
intra-node transport?
Or, is it true that my transport choices are always limited to just
{TCP,UDP} -- independent of the participating nodes' locality (and that I
am thus forced to go over an OSI loopback)?
If my transport choices are only limited to {TCP,UDP} for all node locality,
then I might ask that you consider additional upcoming modern Java transport
options.
With the ambitions of upcoming OpenJDK JEPs, that will make mainstream an
API capabilty that today is only available via sun.misc.Unsafe, Java will
soon have "more complete" transport options that will include all of
{ TCP, UDP, RDMA/SDP, IPC }
Some examples of upcoming accommodating providers=
1. RDMA/SDP: via Infiniband VERBS (works today in JDK 7 on OSI physical
layer IB NICs, does not work over Ethernet)
2. IPC via OpenHFT' SHM as IPC solution (will work this year)
Again, I realize that these transport choices are useful today only in a
very rare use case. However, should these transports be in your offering to
ISPN/JGRPs customers, then ISPN/JGRPs becomes -- like all of Java has
become in recent years -- increasingly more attractive to /all/ HPC Linux
supercomputing use cases (not just ours).
--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/Musings-on-ISPN-JGR...
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
12 years
Distributed executors and Future(s) they return
by Vladimir Blagojevic
Hey,
There is an interesting request from community to include an Address along with a Future returned for a subtask being executed [1].
I think it makes sense what this user wants. We might create Future sub interface that has getAddress method and we can return an object implementing that interface instead of plain Future. In some new major release we can officially change the signature of these DistributedExecutorService methods to return i.e TargetedFuture - it would not break existing clients. Maybe even make TargetedFuture extend NotifyingFuture.
Any thoughts?
Vladimir
[1] https://community.jboss.org/thread/237442
12 years
Row based security & Queries (Was: Design change in Infinispan Query)
by Sanne Grinovero
To clarify some points rised on the thread "Design change in
Infinispan Query", which I don't wish to derail further:
The Query engine can actually apply per-entry user restriction access
in an efficient way which doesn't involve (necessarily) to check each
result; currently this needs specific user coding but:
# it's not too hard as Hibernate Search users do it regularly: we
provide various helpers and examples. Especially in the book :-)
# is not including a pre-canned strategy as -at least in case of our
Hibernate integration - the details of how people want it done are
often exotic.
Essentially a typical solution would work with Filters: a filter is a
bitset which masks potential results from queries, so it's applied
upfront actual scoring and other more complex match operations.
These bitsets are very suited for filters, and are split on segments
so that pre-computed segments related to parts of an index which
didn't change can be reused even if the index as a whole is mutating
continually.
Such a Filter could even encode the response of some external
authorization service on a per-document base (slow but effective), or
it simply represents user group tokens which are applied as tags on
the indexed documents (more efficient as long as role definitions are
stable).
That said, I'm not suggesting that this should be a priority, but I
expect that sometime in the future we could provide a pre-canned
strategy to work out of the box with our security extensions, at least
for the benefit of remote protocols. So let's keep this in mind while
making other design decisions.
-- Sanne
12 years
JavaDocs and API documentation
by Tristan Tarrant
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear distinction between public and private API/SPI. I would
like to clearly mark which of our classes/interfaces are public API.
Should we:
- add some decoration / visual cue to such elements to distinguish them
from the internal stuff
- generate two JavaDoc bundles: one which only contains the public
API/SPIs and one with everything
Tristan
12 years
