Re: [hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally
by Manik Surtani
On 26 Nov 2009, at 09:16, Galder Zamarreno wrote:
> Hi,
>
> Re: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#4267469
>
> I think Brian has a good point here. We don't expose any internal
> information wrt each cache entry's expiry/eviction values. Brian has a
> good point that this could guide him in finding out which entries have
> been last been used, how long they've been in memory and how it could
> tweak expiration/eviction accordingly.
>
> If we don't do anything, I think we run the risk of people being forced
> to get hold of the container, looping through it and getting information
> that they need from inspecting internal classes.
>
> So, I'd suggest that we add a JMX method to CacheDelegate called
> something like:
>
> Map<String, Map<String, long>> getTransientAndMortalityInformation().
>
> (I'm open to suggestions to other names. This is the 1st thing that came
> to my mind)
>
> This would return a Map where the key is the toString form of the cache
> key and the value part is a map where individual transient/mortal
> properties are returned. I.e.
>
> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
> ...]
>
>
> We could event add calculated properties such as 'age' which is current
> - created. This would vary with each call obviously.
Surely that would be hugely expensive? To iterate through the entire collection? And what when you have JOPR polling this value every 5 seconds or something? ;)
>
> As indicated in the forum entry, at least based on this use case, I
> don't see an immediate need to query this type of information given a
> key, although could be potentially useful for other use cases. The
> reason this would not help much right now is because it is Hibernate
> that creates the keys of 2nd level cache (i.e. CacheKey) and these are
> nor meant to be recreated externally, so it'd be hard for external apps
> to get something out of the Infinispan cache directly without going
> through the Hibernate integration layer.
>
> My suggested JMX method could allow for individual transient/mortality
> information to be queried by tools, or other client jmx code. Maybe some
> tools could use that to create a table or something like that which
> could be ordered based on a column? i.e. age. Also, tools or client jmx
> code could convert those longs into whatever they want: seconds,
> minutes...etc
>
> The reason I think JMX is a good candidate here is this is inherently
> monitoring information and it allows us to expose internal information
> via primitives without having to expose internal classes.
>
> Thoughts?
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
Incompatibilites between hibernate-core 3.5.0-Beta-2 and hibernate-annotations 3.4.0GA
by Guenther Demetz
//Hi hiberante-developers,
I don't understand exactly what the statement "*/Bundled with Hibernate
Core as of 3.5.x" /*/(see below/) means, but I'd like to point out that
there are several*
*incompatibilities between hiberante3.jar (3.5beta2) and
hibernate-annotations.jar + hibernate-commons-annotations.jar (3.4.0GA).
This because of overlapping classes with different signature (please see
exceptions below)
The environment with 3.5beta2 works correctly only if in the classpath
hiberante3.jar preceeds the other 2 jars.
Please ignore this post in case the problem is already known
best regards
G.D.
/Snippet of?/ https://www.hibernate.org/6.html
Hibernate Annotations 3.4.0 GA 20.08.2008 Production /
/
*/Bundled with Hibernate Core as of 3.5.x/*
--------------------------------------------------------------------------------------------------------------------
Classpath sequence:??
hibernate-annotations.jar:hibernate-commons-annotations.jar:hibernate3.jar
???? [exec] [hibernatetool] Executing Hibernate Tool with a JPA
Configuration
???? [exec] [hibernatetool] 1. task: hbm2ddl (Generates database schema)
???? [exec] [hibernatetool] SLF4J: This version of SLF4J requires log4j
version 1.2.12 or later. See also
http://www.slf4j.org/codes.html#log4j_version
???? [exec] [hibernatetool] EMMA: collecting runtime coverage data ...
???? [exec] [hibernatetool] An exception occurred while running exporter
#2:hbm2ddl (Generates database schema)
???? [exec] [hibernatetool] To get the full stack trace run ant with
-verbose
???? [exec] [hibernatetool] Problems in creating a configuration for
JPA. Have you remembered to add hibernate EntityManager jars to the
classpath ?
???? [exec] [hibernatetool] java.lang.reflect.InvocationTargetException
???? [exec] [hibernatetool] *java.lang.IncompatibleClassChangeError:
class org.hibernate.cfg.ExtendedMappings has interface
org.hibernate.cfg.Mappings as super class*
------------------------------------------------------------------------------------------------------------------------
Classpath sequence:
hibernate-commons-annotations.jar:hibernate3.jar:hibernate-annotations.jar
???? [exec] [hibernatetool] Executing Hibernate Tool with a JPA
Configuration
???? [exec] [hibernatetool] 1. task: hbm2ddl (Generates database schema)
???? [exec] [hibernatetool] SLF4J: This version of SLF4J requires log4j
version 1.2.12 or later. See also
http://www.slf4j.org/codes.html#log4j_version
???? [exec] [hibernatetool] An exception occurred while running exporter
#2:hbm2ddl (Generates database schema)
???? [exec] [hibernatetool] To get the full stack trace run ant with
-verbose
???? [exec] [hibernatetool] Problems in creating a configuration for
JPA. Have you remembered to add hibernate EntityManager jars to the
classpath ?
???? [exec] [hibernatetool] java.lang.ExceptionInInitializerError
???? [exec] [hibernatetool] *java.lang.ClassCastException:
org.hibernate.annotations.common.reflection.java.JavaReflectionManager
cannot be cast to
org.hibernate.annotations.common.reflection.MetadataProviderInjector
*----------------------------------------------------------------------------------------------------------------------------*
*Classpath sequence:?
hibernate3.jar:hibernate-annotations.jar:hibernate-commons-annotations.jar
???????hibernatetool* *hbm2ddl* OK*
15 years
Re: [hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally
by Galder Zamarreno
FYI
On 11/26/2009 10:16 AM, Galder Zamarreno wrote:
> Hi,
>
> Re: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#4267469
>
> I think Brian has a good point here. We don't expose any internal
> information wrt each cache entry's expiry/eviction values. Brian has a
> good point that this could guide him in finding out which entries have
> been last been used, how long they've been in memory and how it could
> tweak expiration/eviction accordingly.
>
> If we don't do anything, I think we run the risk of people being forced
> to get hold of the container, looping through it and getting information
> that they need from inspecting internal classes.
>
> So, I'd suggest that we add a JMX method to CacheDelegate called
> something like:
>
> Map<String, Map<String, long>> getTransientAndMortalityInformation().
>
> (I'm open to suggestions to other names. This is the 1st thing that came
> to my mind)
>
> This would return a Map where the key is the toString form of the cache
> key and the value part is a map where individual transient/mortal
> properties are returned. I.e.
>
> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
> ...]
>
>
> We could event add calculated properties such as 'age' which is current
> - created. This would vary with each call obviously.
>
> As indicated in the forum entry, at least based on this use case, I
> don't see an immediate need to query this type of information given a
> key, although could be potentially useful for other use cases. The
> reason this would not help much right now is because it is Hibernate
> that creates the keys of 2nd level cache (i.e. CacheKey) and these are
> nor meant to be recreated externally, so it'd be hard for external apps
> to get something out of the Infinispan cache directly without going
> through the Hibernate integration layer.
>
> My suggested JMX method could allow for individual transient/mortality
> information to be queried by tools, or other client jmx code. Maybe some
> tools could use that to create a table or something like that which
> could be ordered based on a column? i.e. age. Also, tools or client jmx
> code could convert those longs into whatever they want: seconds,
> minutes...etc
>
> The reason I think JMX is a good candidate here is this is inherently
> monitoring information and it allows us to expose internal information
> via primitives without having to expose internal classes.
>
> Thoughts?
>
> Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
Re: [hibernate-dev] Programmatic API Doc
by Emmanuel Bernard
Hello Amin,
Looks good. A few omments
- please don't update the rest of the files. Your patch is gigantic
and it's hard to see what you have really changed vs what has been
beautified by your editor.
- I would not emphasize providedId so much as it's a very obscure
feature at the moment.
- I think I would move this section under 4. Mapping entities to the
index structure
- something that will probably makes things easier is to show the
equivalent annotation-based example. People can easily compare.
Emmanuel
On 23 nov. 09, at 08:56, Amin Mohammed-Coleman wrote:
> HI
>
> I've added a patch with regards to the documentation. You'll see its
> not complete but basically I wanted to get an idea on whether the
> structure was ok or not. I'll carry on working on it but I'd be
> grateful if I could get your thoughts on it.
>
>
> Cheers
> Amin
> <programmaticApi23112009.patch>
15 years
Re: [hibernate-dev] Programmatic Mapping patch
by Emmanuel Bernard
On 20 nov. 09, at 15:20, Emmanuel Bernard wrote:
> Hi Amin,
> I've committed your patch, thanks!
> There is still some work and questions remaining but that's a big
> coverage improvement. Now on to the doc to get the release out :)
>
> Here is my raw feedback
>
> 1.
> Interface vs class?
> Should we start using interfaces instead of classes, at least for
> SearchMapping. That way we could hide the getEntityDescriptor()
> method to the users.
> I think we need to start using superclasses or super interfaces to
> enforce the repeated contracts down to the tree of navigation?
>
> 2.
> Should the methods be on IndexedMapping not EntityMapping?
> - fullTextFilterDef
> - analyzerDiscriminator
> - similarity
> Question to Hardy and Sanne, do these concepts make sense on a non
> @indexed element? I can't remember how the parser behaves.
>
> I think these methods should be onn IndexedMapping rather than
> EntityMapping
> - boost
> - providedId
>
> The problem with this approach is that we would need to
> differentiate PropertyMapping and IndexedPropertyMapping. I am not
> sure this additional complexity is worth the extra help to the
> developer.
>
> 3.
> property(String name, ElementType type) should it be replaced with
> specific methods like?
> .field() => conflict with lucene field
> .getter()
>
> 4.
> Is date bridge exclusive to calendar bridge? I think the contract
> expresses that today.
>
> 5.
> ContainedInMapping does not contain the necessary upper methods.
>
> 6.
> I've updated the original ProvidedIdTest, Can you push the same
> changes to the programmatic version of the test.
15 years
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
Re: [hibernate-dev] [infinispan-dev] Querying Infinispan -- Help Needed
by Navin Surtani
Hiya Vinoth,
I just ran my tests locally, and they seem to be working fine.
My class in my test looks like this: -
@ProvidedId(bridge = @FieldBridge(impl = StringBridge.class))
@Indexed(index = "person")
public class Person implements Serializable {
@Field(store = Store.YES)
private String name;
@Field(store = Store.YES)
private String blurb;
@Field(store = Store.YES, index = Index.UN_TOKENIZED)
private int age;
Perhaps if you have a look at the differences between our annotations
and have a play around you'll be able to find out what the issue is. I
used exactly the same annotations as you did
On 19 Nov 2009, at 07:02, Vinoth wrote:
> Hi,
>
> I have a problem in getting through the querying feature of
> infinispan. I am using the technical preview listed in this wiki
> page 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.
Yes, Hibernate Search will throw an exception if you don't specify if
any of your classes are Entities. If there aren't any entities then it
doesn't know what to index :-).
>
> Please let me know if I missed anything here.
>
> Thanks in advance,
> Vinoth
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
15 years
Returned mail: see transcript for details
by Post Office
The original message was received at Thu, 19 Nov 2009 10:54:43 +0530 from lists.jboss.org [149.17.122.174]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
----- Transcript of the session follows -----
... while talking to lists.jboss.org.:
>>> MAIL FROM:"Post Office" <postmaster(a)lists.jboss.org>
<<< 507 "Post Office" <postmaster(a)lists.jboss.org>... Access denied
15 years
