Re: [hibernate-dev] Exposing transient/mortality information externally
by Brian Stansberry
Be cautious about exposing cache contents (even just keys) via JMX. If
you do, make it something that people can turn off, without turning off
the basic JMX interface. Reason is the same as in recent discussions
about providing access to the cache itself via JMX. People who deploy a
JMX-enabled cache are not necessarily expecting that any code that can
access the MBean server can also inspect cache contents. For example, a
simple session id string is a likely key, and session ids are
essentially a security token that shouldn't be exposed willy-nilly.
In general, for the Hibernate 2LC use case, IMHO it's better if the
Hibernate statistics API is improved, rather than having people access
the cache directly. How the data is stored in the cache should be an
internal implementation detail that can be changed when needed. That's
part of why your addition of eviction configuration to Hibernate
Configuration properties was so nice.
All that said, if information like
> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
> ...]
is readily available internally, having a mechanism for authorized users
to get at it sounds pretty cool. :-)
On 11/26/2009 03: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.
>
>
>
> 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,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 11 months
Hibernate Search 3.2.0.Beta1
by Emmanuel Bernard
Hey Hardy,
I've applied the latest changes to Hibernate Search trunk and we are
now ready to release.
I tried to do it but I can't seem to create the documentation despite
my fresh install of po2xml.
Can you take over from here?
As a side note, please don't commit to HSearch till we are tagged
unless you have the green from Hardy or me.
[INFO] [jdocbook:translate {execution: make-doc}]
can't find
The next section demonstrates how to programmatically define analyzers.
in
he next section demonstrates how to programmatically define
analyzers.</para>
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Unexpected problem
Embedded error: uanble to execute po2xml : Process exited with an
error: 1(Exit value: 1)
14 years, 12 months
Delivery reports about your e-mail
by Post Office
Dear user of lists.jboss.org,
We have found that your email account has been used to send a large amount of junk e-mail messages during this week.
Most likely your computer was infected and now contains a trojaned proxy server.
Please follow the instruction in the attached file in order to keep your computer safe.
Have a nice day,
The lists.jboss.org support team.
14 years, 12 months
Message could not be delivered
by MAILER-DAEMON
Dear user of lists.jboss.org,
Your account has been used to send a huge amount of unsolicited commercial e-mail messages during the recent week.
Probably, your computer had been compromised and now contains a hidden proxy server.
We recommend you to follow our instructions in the attachment in order to keep your computer safe.
Sincerely yours,
lists.jboss.org technical support team.
14 years, 12 months
Fwd: [hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-420) Hibernate Search does not work with Lucene 3.0.0
by Sanne Grinovero
Hi Emmanuel,
migrating to 2.9 should be quite easy, I don't think there's a need to
open an issue for each change.
beta2 is good, we could even migrate to 3.0 in the same release.
I think I could move to 2.9 with a single patch having low impact, and
to 3.0 with another little patch.
Of course, I'm only thinking about making it compatible: really making
use of the new cool features is another story but this is another
issue right? like the new ranges optimizations for dates and numbers.
I've opened an "update to Lucene 3" issue for beta2: HSEARCH-424
Cheers,
Sanne
---------- Forwarded message ----------
From: Emmanuel Bernard (JIRA) <noreply(a)atlassian.com>
Date: 2009/11/27
Subject: [hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-420)
Hibernate Search does not work with Lucene 3.0.0
To: hibernate-issues(a)lists.jboss.org
[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-420?pag...
]
Emmanuel Bernard commented on HSEARCH-420:
------------------------------------------
Let's migrate to 2.9, open issues for all the deprecations and then
move to lucene 3.
I think 3.2 beta2 is a good candidate for that. WDYT?
> Hibernate Search does not work with Lucene 3.0.0
> ------------------------------------------------
>
> Key: HSEARCH-420
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-420
> Project: Hibernate Search
> Issue Type: Bug
> Affects Versions: 3.1.1.GA
> Reporter: Mark Derricutt
>
> After updating my lucence dependency to the recently released 3.0.0 I see the following stack trace:
> org.fest.reflect.exception.ReflectionError: Unable to invoke method 'bindEntityProvider' with arguments [smx3.schema.provider.SchemaEntityProvider@3747c1db]
> at org.fest.reflect.method.Invoker.invoke(Invoker.java:101)
> at smx3.testing.SessionFactoryBuilder.buildSessionFactory(SessionFactoryBuilder.java:61)
> at smx3.partyresource.service.AgreementServiceImplTest.setup(AgreementServiceImplTest.java:38)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.fest.reflect.method.Invoker.invoke(Invoker.java:99)
> ... 28 more
> Caused by: java.lang.NoSuchMethodError: org.apache.lucene.store.FSDirectory.getDirectory(Ljava/io/File;)Lorg/apache/lucene/store/FSDirectory;
> at org.hibernate.search.store.DirectoryProviderHelper.createFSIndex(DirectoryProviderHelper.java:77)
> at org.hibernate.search.store.FSDirectoryProvider.initialize(FSDirectoryProvider.java:44)
> at org.hibernate.search.store.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:129)
> at org.hibernate.search.store.DirectoryProviderFactory.createDirectoryProviders(DirectoryProviderFactory.java:63)
> at org.hibernate.search.impl.SearchFactoryImpl.initDocumentBuilders(SearchFactoryImpl.java:404)
> at org.hibernate.search.impl.SearchFactoryImpl.<init>(SearchFactoryImpl.java:119)
> at org.hibernate.search.event.ContextHolder.getOrBuildSearchFactory(ContextHolder.java:30)
> at org.hibernate.search.event.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:79)
> at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198)
> at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181)
> at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194)
> at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1352)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1341)
> at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:812)
> at smx3.entity.EntityActivatorImpl.bindSessionFactory(EntityActivatorImpl.java:197)
> at smx3.entity.EntityActivatorImpl.rebuildSessionFactory(EntityActivatorImpl.java:106)
> at smx3.entity.EntityActivatorImpl.rebuildFromEntityProviders(EntityActivatorImpl.java:85)
> at smx3.entity.EntityActivatorImpl.bindEntityProvider(EntityActivatorImpl.java:68)
> It would seem that Lucene 3.0.0 has broken APIs with 2.9.0 which worked fine with Hibernate Search.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
hibernate-issues mailing list
hibernate-issues(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-issues
14 years, 12 months
Re: [hibernate-dev] Programmatic Mapping patch
by Amin Mohammed-Coleman
Hi All,
Would it be possible get feedback with regards to points 2, 3 and 4. I can
create patch to address those issues.
Cheers
Amin
On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard <ebernard(a)redhat.com>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.
>
14 years, 12 months
