Infinispan Query entity discovery (Was: Re: new Infinispan Query API - ISPN-194)
by Sanne Grinovero
Hello,
I'm forking off this thread, as we never resolved how to cope with the
main issue:
how is Infinispan Query going to be aware of which entities are to be
considered as default targets for a Query?
the realistic ideas so far:
A) class scanning: seems nobody liked this idea, but I'll still
mention it as the other options aren't looking great either.
B) scan known indexes (need to define what the "known indexes" are as
we usually infer that from the classes)
-- could enforce a single index
C) have to list all fully qualified class names in the configuration
D) don't care: consider it a good practice to specify all targeted
types when performing a Query.
E) please suggest :)
The currently implemented solution is D, as it requires no coding at all :)
considering the simplicity of it I'm liking it more the more I think
about it; I could even polish the approach by adding a single line to
log a warning when the user doesn't respect the best practice, or to
mandate it.
Considering that when a Query is invoked specifying the target types
there is no doubt we know the classes, I could add a warning in case
the Query is performed without specifying the type: in that case it
usually implies the query targets all known types, which is always
fine when using Hibernate Search, but could be inconsistent with
Infinispan Query as it might not have discovered all types yet (1), so
a very simple solution is to mandate the type parameter.
[1] - when the Cache interceptor hits an event adding a new type, the
Search engine is reconfigured.
thoughts?
Sanne
2011/4/5 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:
>
>> 2011/4/5 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>
>>> On 5 avr. 2011, at 12:20, Galder Zamarreño wrote:
>>>
>>>>
>>>> On Apr 4, 2011, at 6:23 PM, Sanne Grinovero wrote:
>>>>
>>>>> </snip>
>>>>>
>>>>> there's one catch:
>>>>> when searching for a class type, it will only include results from
>>>>> known subtypes. The targeted type is automatically added to the known
>>>>> classes, but eventually existing subtypes are not discovered.
>>>>>
>>>>> Bringing this issue to an extreme, if the query is not targeting any
>>>>> type, and no indexed types where added to the grid (even if some exist
>>>>> already as they might have been inserted by other JVMs or previous
>>>>> runs), all queries will return no results.
>>>>> How to solve this?
>>>>> - class scanning?
>>>>
>>>> Nope, too expensive.
>>>>
>>>>> - explicitly list indexed entities in Infinispan configuration?
>>>>
>>>> No
>>>>
>>>>> - a metadata cache maintaining a distributed&stored copy of known types
>>>>
>>>> That sounds more appealing. It could be a good middle ground until Search can search for types.
>>>
>>> Do you have any specific idea in mind?
>>>
>>> To magically find types:
>>> - we scan every file system, databases, caches available to the app and look for Lucene metadata => unrealistic
>>> - there is some kind of convention on where the indexes are and we do index scanning at startup => scanning are very likely to be slower that class scanning (potential remote access, bigger dataset etc)
>>> - we enforce one or a fixed number of Lucene indexes for all data in Infinispan => not sure that's a good idea but this can be explored
>>> - we somehow ask the framework using HSearch to fill up classes
>>>
>>> other approaches?
>>
>> why was class scanning discarded in the first answer? as H. Search can
>> auto-discover classes by working on top of JPA entity autodiscovery, I
>> guess that each application node could look into it's own known
>> classpath.
>> After all if some type is not visible to him as it was added from
>> another node from a different app, he won't be able to return
>> instances of it either.
>> We could face the opposite problem of building metadata of classes
>> people doesn't mean to index in this cache.
>
> Right. scanning (class or index) will be a bit aggressive and could build unneeded metadata (or even worse, return unexpected classes).
15 years
Describing infinispan
by Paolo Romano
Hi guys,
we're preparing a paper describing the self-tuning replication mechanism
(Primary backup vs the 2PC-based replication mechanism currently used by
Infinispan), and we'd like to stress how relevant Infinispan is for the
J2EE community, and (I was thinking) in particular for the JBoss AS.
Is it correct if we say that Infinispan is the reference in-memory NoSQL
data grid for the JBoss Application Server, which is the most popular
open source J2EE AS ?
Do you have access to any public statistics on the number of users of
Infinispan/JBoss AS?
Of course, feel free to suggest any other cool phrase to highlight the
relevance of Infinispan in the NoSQL data grid domain!
Cheers,
Paolo
--
Paolo Romano, PhD
Coordinator of the Cloud-TM ICT FP7 Project (www.cloudtm.eu)
Senior Researcher
INESC-ID
Rua Alves Redol, 9
1000-059, Lisbon Portugal
Tel. + 351 21 3100300
Fax + 351 21 3145843
Webpage http://www.gsd.inesc-id.pt/~romanop
15 years
Re: [infinispan-dev] pls provide me Simple STOMP on WebSocket Client in Javascript
by Pavana Kumari
Hi
Am beginner to STOMP. I gone through the STOMP pdf, it was good. Am trying to execute STOMP clients in Javascript
But It is unable to execute var client=Stomp.client(URL) statement. Please help me to resolve the Issue
Regards
Pavana
DISCLAIMER: This email message and all attachments are confidential and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or to mailadmin(a)spanservices.com and destroy the original message. Opinions, conclusions and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN.
15 years
