RpcManagerImpl stats confusion
by Galder Zamarreno
Hi Manik et al,
What's the difference between RpcManagerImpl.replicationCount and
RpcManagerImpl.numReplications?
numReplications is only updated when retrieveState() is called. Maybe
you wanted to call it, numberStateTransfersRequested?
Similar thing happens for totalReplicationTime, it's only updated in
retrieveState(), so maybe you wanted to call it, totalStateTransferTime?
Both numReplications and totalReplicationTime produce
getAverageReplicationTime() which as it is currently, it's rather
confusing. It should say: getAverageStateTransferTime().
We probably wanna add to this a totalReplicationTime though that is
updated in invokeRemotely(), in the same way that replicationCount is
updated. That way we could certainly provider a reliable
getAverageReplicationTime()
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 10 months
Query iterator question
by Bryan Grunow
I didn't get an answer on the message board so I figured I'd try here.
I can only get query results from the cache if the key in the cache is a
String.
I looked at the code in LazyIterator (I didn't check EagerIterator since
it fails so I'm assuming the code is similar) and there is a line that
retrieves the documentId from the extractor and casts it as a String.
The cast works but the documentId (the key) is entered in the cache as
an Integer so the lookup fails. The result count is correct so I know it
finds the results correctly but the lookup fails so I get a null in the
iterator.
Thanks,
Bryan
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
15 years, 10 months
PutIfAbsentStressTest
by Mircea Markus
Hi Sanne,
This test is in the stress package, and disabled by default. All methods are annotated with @Test, so they will get executed despite of the @Test(enabled=false) at the class level.
Is the intention to have the test running or disabled?
Thanks,
Mircea
15 years, 10 months
Re: [infinispan-dev] infinispan and chunkd
by Manik Surtani
Hi Jeff
Sorry for the late reply, it's been a busy couple of weeks. :)
I've cc'd infinispan-dev [1] as there are others who would be interested and may want to pitch in - I recommend your joining the list as well if you haven't already done so. Anyway, comments inline:
On 5 Nov 2009, at 21:24, Jeff Garzik wrote:
>
> Manik,
>
> Just a quick FYI... "chunkd", Project Hail's single node low-level data
> storage service, just received an API and network protocol update to
> make chunkd an even more general remote key-value storage service.
>
> http://hail.wiki.kernel.org/index.php/Chunkd
Nice stuff!
> Two general questions...
>
> * Is there room for chunkd to be a storage backend for Infinispan?
Absolutely. I can see chunkd being an excellent storage node for a CacheStore, either being colocated alongside each Infinispan node (communicating over a local socket).
Another potentially interesting and useful integration point - albeit more complex - is to use chunkd as a DataContainer [2]. You mentioned that chunkd could use a ramdisk partition delegating the memory mgmt to the kernel, thereby buying us storage outside of the JVM heap which could be interesting. I suppose for this to make sense chunkd's operations would have to map to DataContainer - particularly, it would need to support both FIFO and LRU ordering of entries so as to be able to access entries via an iterator. Have you thought about this?
>
> * Is there anyone who might be talked into creating a Java
> interface for chunkd, now that it is _very_ map-like?
Do you actually need one? Just a Map is of limited use. If you want a richer API, folks probably could use Infinispan on top of chunkd (assuming a ChunkdCacheStore) - Infinispan's Cache interface extends ConcurrentMap. Or for a *really* simple API, perhaps what you need is a REST API. I've started a REST-* caching [3] [4] standardisation effort, haven't really had time to post much there as yet but it would likely look a lot like Infinispan's own REST API [5].
Cheers
Manik
[1] https://lists.jboss.org/mailman/listinfo/infinispan-dev
[2] http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/container/Dat...
[3] http://www.jboss.org/reststar
[4] http://groups.google.com/group/reststar-caching
[5] http://www.jboss.org/community/wiki/InfinispanRESTserver
>
> Writing a good Java interface requires knowledge of the available
> standards, and I am probably the worst possible choice for doing
> that.
>
> Regards,
>
> Jeff
>
>
>
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 10 months
Hibernate Search DSL ideas
by Navin Surtani
Heya,
I was just thinking last night about a couple of things about the DSL.
Mainly, instead of having lots of return types, for example you
created a BooleanContext and a Negatable version if the Occur clause
was MUST. I was wondering, instead of having separate contexts, is it
easier to have one - and then if a user calls a buildQuery() without
sufficient information to actually build one we throw an exception?
I think this is cleaner in some ways because we don't have to create
so many different types of class, and we're always returning the same
instance. However, the drawback is that by this method we "allow the
user to make a mistake" and will be needing to throw exceptions. So
here's where the discussion starts - what are pros/cons of each system
and which wind up being a better one to build? Personally, I think
having a single class context is better because 1 - it's simpler to
build and 2 - as long as classes are documented properly and
exceptions thrown are clear as to what the issue is then we're okay.
Ideas? Thoughts?
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
15 years, 10 months
Querying Infinispan -- Help Needed
by Vinoth
Hi,
I have a problem in getting through the querying feature of infinispan. I am
using the technical preview listed in this wiki
page<http://www.jboss.org/community/wiki/QueryingInfinispan>with the
help of the sample code provided in the same page.
I used the following properties for the second argument in QueryHelper
Constructor.
#hibernate.properties
hibernate.search.default.directory_provider
org.hibernate.search.store.FSDirectoryProvider
hibernate.search.default.indexBase=/usr/vin/lucene/indexes
This is my class for Hibernate Search
@ProvidedId
@Indexed
public class Item {
@Field
private String name;
@Field
private String description;
...// getters and setters
}
I have included the @ProvidedId since QueryHelper instantiation validates
the classes based on this annotation.
*Note :: QueryHelper.validateClasses() -- This is to check that both the
@ProvidedId is present and the the @DocumentId is not present. This is
because don't want both of these 2 annotations used at the same time.*
When I used the @Indexed annotation for the above class, it throws an
exception while instantiating the QueryHelper.
<Exception Snippet>
java.lang.NullPointerException
at
org.hibernate.search.engine.DocumentBuilderIndexedEntity.init(DocumentBuilderIndexedEntity.java:151)
at
org.hibernate.search.engine.DocumentBuilderContainedEntity.<init>(DocumentBuilderContainedEntity.java:93)
at
org.hibernate.search.engine.DocumentBuilderIndexedEntity.<init>(DocumentBuilderIndexedEntity.java:128)
at
org.hibernate.search.impl.SearchFactoryImpl.initDocumentBuilders(SearchFactoryImpl.java:409)
at
org.hibernate.search.impl.SearchFactoryImpl.<init>(SearchFactoryImpl.java:119)
at
org.infinispan.query.backend.QueryHelper.<init>(QueryHelper.java:87)
<Exception Snippet>
When I removed that @Indexed annotation, QueryHelper got instantiated but it
throwed some exception when it hits CacheQuery.getBasicQuery() method, where
it forms lucene query string with the help of QueryParser.
org.hibernate.HibernateException: There are no mapped entities. Don't forget
to add @Indexed to at least one class.
Please let me know if I missed anything here.
Thanks in advance,
Vinoth
15 years, 10 months
Re: [infinispan-dev] Querying Infinispan -- Help Needed
by Vinoth
Hi Navin,
I am getting the same error after replacing all this annotations to my test
class.
java.lang.NullPointerException
at
org.hibernate.search.engine.DocumentBuilderIndexedEntity.init(DocumentBuilderIndexedEntity.java:151)
at
org.hibernate.search.engine.DocumentBuilderContainedEntity.<init>(DocumentBuilderContainedEntity.java:93)
at
org.hibernate.search.engine.DocumentBuilderIndexedEntity.<init>(DocumentBuilderIndexedEntity.java:128)
at
org.hibernate.search.impl.SearchFactoryImpl.initDocumentBuilders(SearchFactoryImpl.java:409)
at
org.hibernate.search.impl.SearchFactoryImpl.<init>(SearchFactoryImpl.java:119)
at
org.infinispan.query.backend.QueryHelper.<init>(QueryHelper.java:87)
If you want I can share my test code for your reference.
Also kindly share your test code to my mail (s.venoth(a)gmail.com)
Thanks in advance,
Vinoth
15 years, 10 months
