Which QueryBuilder ?
by Sanne Grinovero
It seems we have now 2 different interfaces both names "QueryBuilder"
when using Infinispan Query.
One is coming from Hibernate Search, and represents the "classic" way
to build queries for Infinispan Query in embedded mode.
The other one is new, and represents the simplified approach, also
implemented for remote queries.
Could we find an alternative name for the new API?
It's certainly going to be confusing, even more when we'll have to
document the differences, and which one is more suited for one use
cases vs. another.
Cheers,
Sanne
12 years, 10 months
Re: [infinispan-dev] Need help
by Sanne Grinovero
Hi Pedro,
looks like you're diving in some good fun :-)
BTW please keep the dev discussions on the mailing list, adding it.
inline :
On 4 October 2013 22:01, Pedro Ruivo <pedro(a)infinispan.org> wrote:
> Hi,
>
> Sanne I need your expertise in here. I'm afraid that the problem is in
> FileListOperations :(
> I think the FileListOperations implementation needs a transactional cache
> with strong consistency...
>
> I'm 99% sure that it is originating the java.lang.AssertionError: file XPTO
> does not exist. I find out that we have multiple threads adding and removing
> files from the list. The scenario in [1] we see 2 threads loading the key
> from the cache loader and one thread adds a file and other removes. the
> thread that removes is the last one to commit and the file list is updated
> to an old state. When it tries to updat an index, I got the assertion error.
Nice, looks like you're on something.
I've never seen specifically an AssertionError, looks like you have a
new test. Could you share it?
Let's step back a second and consider the Cache usage from the point
of view of FileListOperations.
Note that even if you have two threads writing at the same time, as
long as they are on the same node they will be adding/removing
elements from the same instance of a ConcurrentHashMap.
Since it's the same instance, it doesn't matter which thread will do
the put operation as last: it will push the correct state.
(there is an assumptions here, but we can forget about those for the
sake of this debugging: same node -> fine as there is an external
lock, no other node is allowed to write at the same time)
But you are focusing on CacheStore operations, I can see how that
might be different in terms of implementation but it is not acceptable
that the CacheStore is storing a different state than what we have in
memory.
I don't expect to need a Transaction for that ? Writes need *always*
to be applied in the right order so that the CacheStore content
matches the in-memory content.
So -1 for the problem being in FileListOperations, it's in the
CacheStore. Also, I've run plenty of stress tests on in-memory Caches
and never hit problems: if Infinispan changes the semantics by
enabling a CacheStore, that's a critical issue.
Also, this needs to work correctly with async cachestores.
> Also, I was able to "reproduce" the EOF. This was the first problem I found
> and it is related to DefaultCacheManager.startCaches(String... cacheName),
> that is starting the caches in separated threads. The SingleFileStore is
> failing to start but the exception in "swallow" by the thread. So, Hibernate
> Search is not notified and it uses the cache anyway. To make it worst, the
> cache accepts the requests but it is not persisting the data. This creates
> the EOF in the restart... I will open a JIRA about it to discuss it (maybe
> throw an exception in startCaches? and throw exception if any operation is
> invoked in a non-successfull started cache?)
+1 on the exception on startCaches, should not be swallowed!
But why is SingleFileStore throwing an exception?
Thanks a lot, very interesting.
Sanne
>
> Any comments?
>
> If I was not clear let me know :)
>
> Thanks!
> Pedro
>
> [1]https://gist.github.com/pruivo/93edeb82a21e9827d2c9
12 years, 10 months
Infinispan 6.0.0.CR1 is available!
by William Burns
Dear Infinispan community,
We are proud to announce the first candidate release for Infinispan 6.0.0.
As many of you would expect from a candidate release this version
contains a multitude of bug fixes/enhancements to get to a stable
6.0.0 release.
For a complete list of features and fixes included in this release
please refer to the release notes [1]. Visit our downloads section to find
the latest release [2] and if you have any questions please check our
forums, our mailing lists or ping us directly on IRC.
Thanks to everyone for their involvement and contributions!
- Will
[1] https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310799&versi...
[2] http://infinispan.org/download/
12 years, 10 months
Warnings vs. Fail Fast
by Sanne Grinovero
Currently if a cache is configured with indexing enabled, but the
Query module isn't on classpath, you get a simple warning.
I think this should fail with a configuration validation error; it's
not just safer but also consistent with many other validations.
I've created ISPN-3583 and patch is ready.. any good reason to not apply it?
Sanne
12 years, 10 months
Infinispan Query API changes
by Sanne Grinovero
Hi,
just a heads up that I've been moving some APIs around from
org.infinispan.query:
https://github.com/infinispan/infinispan/pull/2131
In particular I think that CapeDwarf is using some methods from
org.infinispan.query.SearchManager
which are no longer exposed; the fix is simple, cast any SearchManager
you might have into a
org.infinispan.query.spi.SearchManagerImplementor
SearchManagerImplementor is meant to be an SPI, so a relatively stable
interface for projects like CD but not expected to be used by every
day users.
Sanne
12 years, 10 months
input JSON -> convert -> put into ISPN cache & ready for Queries
by Tomas Sykora
Hi team!
I need to ask for your help.
It's connected to the OData endpoint. (https://issues.jboss.org/browse/ISPN-2109) I was thinking about the design etc. and it would be nice to map OData queries to Infinispan queries so clients can get their results based on particular query.
You know, there is basically not much to do with only schema-less key-value store. Like exposing only values to clients based on their key requests does not fully use OData capabilities.
So I was thinking about something like that...
>From any client you are sending JSON object (for example a Book, with variables: title, author, description) to OData service and would like to store query-able Book Object value into the cache "under" some key.
So you go: JSON --> to query-able Book.class Object --> cache.put("key", bookFromJson);
Then in pseudo query: get-me-books-filter-description-contains-"great IT book"-top-N-results --> issue query on cache, get results --> transform returned Books.class into JSON, return to client
My question is:
How to transform JSON input, which is in most cases simple String build according to JSON rules, into object, which is query-able and can be put into the cache.
The thing is that you usually have java class:
@Indexed
Book {
@Filed String title;
@Filed String author;
etc. etc.
I simply don't know how to create an object ready for queries, or even annotated class and instantiate it for further put into the cache.
I'm discovering this, recently: http://www.jboss.org/javassist
Or can you see there any other, maybe totally different, approach how to do it?
THANK YOU very much for any input!
I'm stuck on this right now... that's why I'm asking for a help.
Have a nice day all!
Tomas
12 years, 10 months
