Fwd: ServiceLoader and @ProviderFor
by Hardy Ferentschik
Accidentally only replied to Steve
> On Fri 05 Oct 2012 03:14:57 PM CDT, Hardy Ferentschik wrote:
>> No strong opinion to be honest. I have not had any problems with managing the service files and since refactoring in Idea consider text files as well it is not such a big issues IMO. Using any annotation processor always adds also a bit of pixie dust. Someone new to the source/ build needs to put several pieces together to understand how things fit together.
>>
>> On the other hand, we have already several APs in the build what does one more matter ;-) If others things it makes there live easier ...
>>
>> --hardy
>>
>>
>>
>> On 5 Oct 2012, at 21:23, Steve Ebersole <steve(a)hibernate.org> wrote:
>>
>>> https://code.google.com/p/spi/
>>>
>>> ^^ defines an annotation and processor for helping with services in the
>>> JDK ServiceLoader sense.
>>>
>>> For example, if you wanted to implement Integrator:
>>>
>>> @ProviderFor(Integrator.class)
>>> public void class MyIntegrator implements Integrator {
>>> ...
>>> }
>>>
>>> The AP then:
>>> 1) validates your defined services (not really sure what this means
>>> behind making sure you define a no-arg ctor).
>>> 2) manages your
>>> META-INF/services/org.hibernate.integrator.spi.Integrator file for you
>>>
>>> Just wanted to see what y'all thought of including this for building.
>>> It is not a runtime dependency at all! More I am just wondering if
>>> y'all thought this made it easier/better to manage the META-INF/services
>>> provider file.
>>>
>>>
>>> --
>>> steve(a)hibernate.org
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> steve(a)hibernate.org
> http://hibernate.org
14 years
Accessing annotation properties values
by Łukasz Antoniak
Hello Team,
In Envers code we use ReflactionManager and XProperty#getAnnotation(Class<T>) quite often. While working on metamodel branch, I
have started replacing all those calls with JandexHelper#getValue(AnnotationInstance, String, Class<T>) method. The code became
less type safe and grew in size. The only solution that comes to my mind is to create annotation proxy that directs calls to
underlying AnnotationInstance. Something like:
public static <T> T createAnnotationProxy(final AnnotationInstance annotationInstance, final Class<T> annotation) {
try {
final ProxyFactory proxyFactory = new ProxyFactory();
proxyFactory.setInterfaces( new Class[] { annotation.getClassLoader().loadClass( annotation.getName() ) } );
final Class proxyClass = proxyFactory.createClass();
final ProxyObject proxyObject = (ProxyObject) proxyClass.newInstance();
proxyObject.setHandler( new MethodHandler() {
@Override
public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
String executedMethodName = thisMethod.getName();
if ( "toString".equals( executedMethodName ) ) {
return proxyClass.getName() + "@" + System.identityHashCode( self );
}
return JandexHelper.getValue( annotationInstance, executedMethodName, Object.class );
}
} );
return (T) proxyObject;
}
catch ( Exception e ) {
throw new HibernateException( e );
}
}
This allows to:
Audited audited = createAnnotationProxy( auditedAnnotationInstance, Audited.class );
ModificationStore modStore = audited.modStore();
RelationTargetAuditMode relationTarget = audited.targetAuditMode();
I have initially shown the above implementation to Hardy and we were wondering what you all think of this approach. Of course
executing such method increases memory usage and decreases performance, but from design point of view, I can think of situations
where it fits.
Regards,
Lukasz
14 years
ServiceLoader and @ProviderFor
by Steve Ebersole
https://code.google.com/p/spi/
^^ defines an annotation and processor for helping with services in the
JDK ServiceLoader sense.
For example, if you wanted to implement Integrator:
@ProviderFor(Integrator.class)
public void class MyIntegrator implements Integrator {
...
}
The AP then:
1) validates your defined services (not really sure what this means
behind making sure you define a no-arg ctor).
2) manages your
META-INF/services/org.hibernate.integrator.spi.Integrator file for you
Just wanted to see what y'all thought of including this for building.
It is not a runtime dependency at all! More I am just wondering if
y'all thought this made it easier/better to manage the META-INF/services
provider file.
--
steve(a)hibernate.org
http://hibernate.org
14 years
Re: [hibernate-dev] Accessing annotation properties values
by Steve Ebersole
Probably you can cache it by AnnotationInstance, so maybe something
like this instead:
class AnnotationProxyBuilder {
private final Map annotationProxyMap = new ...;
public <T> T getAnnotationProxy(final AnnotationInstance
annotationInstance, final Class<T> annotationClass) {
T annotationProxy = (T) annotationProxyMap.get(
annotationInstance );
if ( annotationProxy == null ) {
annotationProxy = buildAnnotationProxy( annotationInstance,
annotationClass );
annotationProxyMap.put( annotationInstance, annotationProxy
);
}
return annotationProxy;
}
private <T> T buildAnnotationProxy(final AnnotationInstance
annotationInstance, final Class<T> annotationClass) {
// as before...
}
}
--
steve(a)hibernate.org
http://hibernate.org
14 years
4.1.8
by Steve Ebersole
Unless there are objections (and volunteer to do it), I plan on holding
off on 4.1.8 release.
--
steve(a)hibernate.org
http://hibernate.org
14 years
Regression after upgrade to 4.1.7.Final
by Guillaume Smet
Hi,
We just upgraded to Hibernate 4.1.7.Final (from 4.1.6.Final) and we
have a pretty bad regression with 4.1.7 and Hibernate Search 4.1.1.
We have the following stack trace when saving an object:
Caused by: org.hibernate.HibernateException: Error while indexing in
Hibernate Search (before transaction completion)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:186)
at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:662)
at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:307)
at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:607)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:105)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:75)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:512)
... 47 more
Caused by: java.lang.NullPointerException
at org.hibernate.engine.internal.StatefulPersistenceContext.getLoadedCollectionOwnerOrNull(StatefulPersistenceContext.java:851)
at org.hibernate.event.spi.AbstractCollectionEvent.getLoadedOwnerOrNull(AbstractCollectionEvent.java:75)
at org.hibernate.event.spi.InitializeCollectionEvent.<init>(InitializeCollectionEvent.java:36)
at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1799)
at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:524)
at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:212)
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:520)
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:125)
at org.hibernate.collection.internal.PersistentBag.iterator(PersistentBag.java:266)
at org.hibernate.search.engine.spi.AbstractDocumentBuilder.appendContainedInWorkForInstance(AbstractDocumentBuilder.java:296)
at org.hibernate.search.engine.impl.WorkPlan$PerEntityWork.processContainedIn(WorkPlan.java:525)
at org.hibernate.search.engine.impl.WorkPlan$PerClassWork.processContainedInAndPrepareExecution(WorkPlan.java:297)
at org.hibernate.search.engine.impl.WorkPlan.processContainedInAndPrepareExecution(WorkPlan.java:144)
at org.hibernate.search.backend.impl.WorkQueue.prepareWorkPlan(WorkQueue.java:135)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:71)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.beforeCompletion(PostTransactionWorkQueueSynchronization.java:86)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:183)
... 54 more
I don't know if it's something obvious or if you need a self contained
test case to reproduce it.
I haven't created a JIRA because I don't know if it's an
incompatibility between Hibernate Search 4.1.1 and Hibernate 4.1.7 or
a real bug (either in HHH or HSEARCH).
Feel free to ping me for more information or any further action.
Thanks.
--
Guillaume
14 years
First Beta of Hibernate OGM with Infinispan, Ehcache and MongoDB support
by Emmanuel Bernard
I am very happy to finally get this release out. We have kept it close
to our chest for too long. In a few keywords: better infinispan support,
mongodb support, ehcache support, performance and the foundation for our
query support.
For people unfamiliar with Hibernate OGM, this is our Hibernate
experiment for NoSQL datastores.
Read more in our blog post http://goo.gl/aDwae
Emmanuel
14 years
Re: [hibernate-dev] Runtime efficiency: sharing some profiling output
by Steve Ebersole
We do.
On 10/02/2012 03:31 PM, Andrig Miller wrote:
>
>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve(a)hibernate.org>
>> To: "Sanne Grinovero" <sanne(a)hibernate.org>
>> Cc: "John O'Hara" <johara(a)redhat.com>, spederse(a)redhat.com, "Andrig Miller" <anmiller(a)redhat.com>, "Jeremy Whiting"
>> <jwhiting(a)redhat.com>, "Will Reichert" <wreicher(a)redhat.com>, "Hibernate" <hibernate-dev(a)lists.jboss.org>
>> Sent: Tuesday, October 2, 2012 1:43:51 PM
>> Subject: Re: [hibernate-dev] Runtime efficiency: sharing some profiling output
>>
>> See comments inline...
>>
>> On Tue 02 Oct 2012 01:13:39 PM CDT, Sanne Grinovero wrote:
>>
>>> # IdentityMap
>>> Some performance is lost in the well known
>>> org.hibernate.engine.internal.StatefulPersistenceContext;
>>> especially
>>> the IdentityMap and it's need for System.identityHashCode is
>>> demanding.
>>> New in this run is the surprising cost of #clear() : 0,5% CPU.. not
>>> alarming, but it looks like I can blame again IdentityMap,
>>> specifically: concurrentEntries.
>>
>> We have discussed the IdentityMap concerns quite a few times in past
>> few weeks. For background, this is mainly a problem with
>> PersistenceContext and the fact that it holds a few identity-based
>> (rather than equality-based) Maps to track various states related to
>> entities and collections. The bottleneck here is actually
>> System#identityHashCode we have since found, which is a native call.
>> Same thing for Object#hashCode, even if we could consistently rely on
>> it.
>>
>> This can be at least partially alleviated by moving to bytecode
>> enhancement and offloading the state maintained in PersistenceContext
>> to the enhanced entity classes. Of course this is a non-simple
>> change
>> and we really do not know what other performance problems this might
>> then cause.
>>
>>
>>> # DefaultEntityAliases.intern
>>> Why are we interning this?
>>> org.hibernate.loader.DefaultEntityAliases.intern(String[])
>>> If they are constants, I guess they could be reused rather than
>>> re-computed all the time.. in fact, see next point:
>>>
>>> # Aliases and other string generations
>>> It seems Hibernate ORM is generating property aliases and other
>>> little
>>> Strings all the time; this test isn't using any HQL, just direct
>>> loading of entities via primary keys or by following relations from
>>> other managed entities.
>>
>> Isn't there a point where interning becomes wasteful? Surely there
>> must be. What is that tipping point?
>>
>>
>>> #
>>> org.hibernate.type.descriptor.sql.IntegerTypeDescriptor.getExtractor(JavaTypeDescriptor<X>)
>>> Could we avoid returning a new instance on each demand ?
>>
>> I am not sure how since in many cases we rely on being able to swap
>> those incoming JavaTypeDescriptors. Suggestions welcome.
>>
>>
>>> # iterators on
>>> org.hibernate.internal.util.collections.ConcurrentReferenceHashMap.ConcurrentReferenceHashMap
>>> Why are we having a concurrent Map in the
>>> StatefulPersistenceContext
>>> ? I thought this class wasn't meant to be shared among multiple
>>> threads?
>>
>> As far as I know, the important piece is more the references. AFAIK
>> there are no non-concurrent reference map implementations available
>> in
>> any of our current dependencies.
>>
>
> Could you set the concurrency level to one?
>
> Andy
>
>>
>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>>
--
steve(a)hibernate.org
http://hibernate.org
14 years
Runtime efficiency: sharing some profiling output
by Sanne Grinovero
Hi all,
I had this draft email which I apparently never sent, about some
profiling metrics I've taken in May; so relatively outdated. Also
while it stresses Hibernate ORM heavily, my goal was to check sanity
of Hibernate Search; I'm not sure anymore what version it was exactly,
but for sure it was whatever was just released in beginning of May.
Since we're discussing performance now, maybe it's worth sharing after all.
To get to these observations I run it several times with a mixture of
JProfiler, OProfile, JConsole.
Cheers,
Sanne
======
I'm having some profiler runs on a MassIndexer job, loading the
Wikipedia dump out of a MySQL instance and dumping it into a Lucene
index; it's all run on my laptop, the required disk size is at around
120GB to run this test.
This job can take a while: just running the initial COUNT(*) operation
used by Hibernate Search to estimate to overall effort takes ~40
minutes; both MySQL and Lucene indexes are sharing the same single SSD
drive (a Plextor M3).
The good news is that we're pretty efficient, I don't see any mayor
bottleneck - glad so as we didn't have big problems last time I
checked a month ago - it's actually very nice to see how efficient we
are today: my performance is constrained by I/O and the average CPU
usage fluctuates between 5% and 20%.
As expected the Lucene text processing is the peak operations; the top
5 CPU consumers are in the org.apache.lucene code; adding them up,
Lucene takes around 33% of total CPU time (relative to all the CPU
this JVM is taking). Looking into what Lucene is doing, it seems that
we could help it a bit by pre-interning the field names and keeping
these in a constants pool -> HSEARCH-1127.
Looking further for resource consumers, a note for personal
satisfaction is that no classes from org.hibernate.search can be found
on the first page of CPU consumers, but LuceneOptionsImpl is being
highlighted as a hotspot in the object allocation view -> HSEARCH-1128
=== Looking now into Hibernate ORM:
# IdentityMap
Some performance is lost in the well known
org.hibernate.engine.internal.StatefulPersistenceContext; especially
the IdentityMap and it's need for System.identityHashCode is
demanding.
New in this run is the surprising cost of #clear() : 0,5% CPU.. not
alarming, but it looks like I can blame again IdentityMap,
specifically: concurrentEntries.
# DefaultEntityAliases.intern
Why are we interning this?
org.hibernate.loader.DefaultEntityAliases.intern(String[])
If they are constants, I guess they could be reused rather than
re-computed all the time.. in fact, see next point:
# Aliases and other string generations
It seems Hibernate ORM is generating property aliases and other little
Strings all the time; this test isn't using any HQL, just direct
loading of entities via primary keys or by following relations from
other managed entities.
=== Looking into allocation hot-spots:
# org.hibernate.type.descriptor.sql.IntegerTypeDescriptor.getExtractor(JavaTypeDescriptor<X>)
Could we avoid returning a new instance on each demand ?
# iterators on
org.hibernate.internal.util.collections.ConcurrentReferenceHashMap.ConcurrentReferenceHashMap
Why are we having a concurrent Map in the StatefulPersistenceContext
? I thought this class wasn't meant to be shared among multiple
threads?
# Proxy of resultSets
This one was tricky. It seems we generate small sized, but huge
amounts of small primitive wrappers.
It turns out that this happens while extracting values from the
resulting java.sql.ResultSet after any query: the return types of
methods such as #getInt and #getBoolean are obviously defeined as
primitives.
Consistently to this API (couldn't be otherwise as it's the interface)
all points in our code using ResultSet expect a primitive. But the
InvocationHandler#invoke mandates returning an Object, and we're
applying an interceptor to the actual ResultSet via
org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.
In short, it turns out that every time such a method is invoked, the
JVM seems to do autoboxing+unboxing instead of being clever.. could
there be a way to avoid autoboxing for each field being read from the
database? Hironically, most of the times we actually need to box it
right after again, so an alternative would be to have it box only
once?
# Hibernate Search DocumentBuilder
Creation of Lucene Documents is relatively allocation-intensive.. I
guess it's expected but maybe worth a closer look in the future.
=== Thread contention:
it looks like the BlockingQueue is a huge waste of CPU - I'll need to
change this structure for something better suited.
== Conclusions..
Nothing which needs immediate attention, but hope it gives some
ideas.. Why I did it then? Need to run some tests on the Infinispan
Lucene Directory, need to rebuild my big index to collect some up to
date metrics.. might as well have a look if I can make it work a bit
faster :D
14 years
