Re: [hibernate-dev] [HSEARCH] Worker Configuration

[Emmanuel Bernard]

> 
> BTW can you or Sanne or someone else please take look at the class 
> AvroSerializationProvider, line 73.
> Is it really needed to log for every instance of AvroSerializationProvider 
> the same
> information? I have started today for the first time the application server 
> with the
> new Hibernate Search and our application and I have seen this message more
> than 100 times in the log file. I doubt it should be logged in the 
> constructor.
> IMHO a static initialization block would be a better place.


We have identified the problem but that's a little bit more complicated than 
that.
https://hibernate.onjira.com/browse/HSEARCH-1100
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HSEARCH] Proposal to change the default value of Field#norms()

[Emmanuel Bernard]

On 9 mai 2012, at 00:43, Andrej Golovnin wrote:

> Hi Hardy,
> 
>> It depends. Maybe you want to boost any of these fields ad index time.
> 
> OK, what about the document id? It is indexed with NOT_ANALYZED_NO_NORMS.
> As far as I understand (please correct me if I'm wrong) to boost fields at 
> index time
> norms must be enabled for those fields. And because Hibernate Search uses for 
> document ids
> NOT_ANALYZED_NO_NORMS, adding @Boost to a document id would have no effect.
> Although I'm not sure, someone really needs this. But it should be at least 
> documented.

@DocumentId is special as we need to make sure we can lookup by its exact 
value. So Hibernate Search takes over the responsibility to set the right 
options.
Plus it's unlikely that you need to "full-text" search an id field. If you need 
to, you can use an extra @Field on it.

Can you open a JIRA issue to clarify this in 
http://docs.jboss.org/hibernate/search/4.1/reference/en-US/html_single/#basic-mapping
 ?
Even better, can you propose the change as a GitHub pull request? :)

> 
> Also it is also not clear from the Hibernate Search documentation, what will 
> happen
> if I have following annotation on a field:
> 
> @Field(boost=@Boost(1.2f), norms = Norms.NO)
> private String description;
> 
> Would I see a warning or maybe an error message from Hibernate Search?
> Does make such combination sense?

I don't think we raise an exception, we should do something indeed. Do you want 
to open the JIRA and possibly provide a patch via a GitHub pull request?

> 
>> From http://www.lucidimagination.com/content/scaling-lucene-and-solr#d0e71
> norms may not be useful for short or non full text fields. I personally 
> consider
> Enums, boolean/int/short, date, OIDs as short and non full text fields.
> And in my application those fields are majority. We have 130 indexes.
> Some of this indexes are shared by multiple entities. So I would guess
> that we have ca. 140-150 indexed entities +  a lot of IndexEmbedded.
> Of course I could do search&replace. But at some point a developer would
> forget to add "norms = Norms.NO" to a field and our application would start
> consuming more memory. And this is my dilemma. May be I can add an
> automatic test to our build process which would force developers to add
> "norms = Norms.NO". Alternative solution for would be to have a custom
> Hibernate Search version, but I don't like this idea. I will discuss with my 
> team
> what is the best way to solve this small problem.

I think stereotypes would be best. For numbers, I encourage you to use 
@NumericField. I don't believe these are normed and they are for sure more 
optimized.

> Btw Is it possible that OIDs added to index by IndexedEmbedded have
> norms? Luke shows me it in two different indexes. Could someone
> else please verify it? If it is the case, it would be nice if Hibernate Search
> would have the same behavior for OIDs added to index either
> by DocumentId or by IndexedEmbedded, e.g. index them with
> NOT_ANALYZED_NO_NORMS.

I am not following you. What's an OID.

> 
> I understand that for you as a framework provider it is difficult to find a 
> golden path
> which would satisfy every framework user. I think Sanne's suggestion
> with "@Stereotype - like user annotations" may help us to achieve this goal.
> 
> Btw Hibernate Search and Hibernate helped us to create a really cool
> product, so kudos to all who have contributed to this great projects!
> 
> Best regards,
> Andrej Golovnin
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Released Hibernate Search 4.1.1.Final

[Sanne Grinovero]

Hello all,
we just uploaded artifacts and distribution bundles for Hibernate
Search 4.1.1.Final; for all people using 4.1.0 it's recommended to
upgrade!

More information on the blog:
http://in.relation.to/Bloggers/HibernateSearch411FinalFixFileHandleLeakAndMore

Cheers,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Validator 4.3.0.Final seen in the wild

[Hardy Ferentschik]

For more info about $subject see in.relation.to - 
http://in.relation.to/23184.lace

--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate 4.x, JTA(BMT) transactions no longer interchangeable with Hibernate transaction facade?

[Zachary Kurey]

Hi all,

Am I correct in my interpretation that Hibernate 4 no longer supports
interchangeably being able to use either the Hibernate transaction
facade(session.beginTransaction) vs. UserTransaction or CMT?

I say this because it appears that I always must call
session.beginTransaction() when configured to use
JTATransactionFactory, in order to have JtaTransaction->local status
of active.  If local status is not active Hibernate makes no attempt
to check the provided JtaPlatform if there is a user transaction in
process and blows up whenever trying to execute any changes to the db.

In 3.x this worked fine since
JTATransactionFactory->isTransactionInProgress always tried to find
the configured transaction manager and checked the transaction status
properly.  But in 4.x I'm not seeing how local status gets set to
active to prevent a blow up unless I both call userTransaction.begin()
AND session.beginTransaction()...  The same problems exist when
interacting through the EntityManager API.

Even in the ManagedDrivingTest it looks like it is assumed that the
client will call session.beginTransaction() after either a CMT or BMT
has been started.  I would cut over to using the Hibernate facade
exclusively, but now it throws 'nested transactions not supported' if
beginTransaction is invoked multiple times.  The Spring
PlatformTransactionManager API deals with multiple layered invocations
more gracefully, so I've mostly used that in the past for programmatic
transaction management.  But regardless, looking at the source there
seems to be a new requirement to always have
session.beginTransaction() invoked in application code.

I've spent days trying to figure out if I've made a configuration
mistake, and at this point I'm at the conclusion that either Hibernate
behavior in this area was intentionally changed, or that this is a
bug.  If its a bug it would probably break a lot of apps upgrading
from 3.x to 4.x that use programmatically controlled transactions.  So
I thought I'd just reach out on the mailing list for clarification, or
to have an obvious misconfiguration or misunderstanding corrected.

For more info on my JTA config there is a forum post I made that is
unrelated(realized my error on that topic) here:
https://forum.hibernate.org/viewtopic.php?p=2454363

Thanks,
Zach
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HSEARCH] Proposal to change the default value of Field#norms()

[Andrej Golovnin]

Hi Emmanuel,

> Can you open a JIRA issue to clarify this in 
> http://docs.jboss.org/hibernate/search/4.1/reference/en-US/html_single/#basic-mapping
>  ?
> Even better, can you propose the change as a GitHub pull request? :)

Sure. :-)

>> 
>> @Field(boost=@Boost(1.2f), norms = Norms.NO)
>> private String description;
>> 
>> Would I see a warning or maybe an error message from Hibernate Search?
>> Does make such combination sense?
> 
> I don't think we raise an exception, we should do something indeed. Do you 
> want to open the JIRA and possibly provide a patch via a GitHub pull request?

OK, I will do that. But creating patch will take some time.

>> Btw Is it possible that OIDs added to index by IndexedEmbedded have
>> norms? Luke shows me it in two different indexes. Could someone
>> else please verify it? If it is the case, it would be nice if Hibernate 
>> Search
>> would have the same behavior for OIDs added to index either
>> by DocumentId or by IndexedEmbedded, e.g. index them with
>> NOT_ANALYZED_NO_NORMS.
> 
> I am not following you. What's an OID.

Suppose you have following classes:

@Entity
public PostalAddress {

@Id
private String OID;
.
}

@Entity
@Indexed
public Partner {

@Id
private String OID;

@OneToOne
@IndexEmbedded(depth = 1)
private PostalAddress defaultAddress;
   
}

The Lucene document for Partner would contain the field
OID from Partner indexed with NOT_ANALYZED_NO_NORMS
and it will contain also the field "defaultAddress.OID". But the
field "defaultAddress.OID" would have norms. This is what I see
at least with Luke in my indexes. I think the field "defaultAddress.OID"
should be also indexed with NOT_ANALYZED_NO_NORMS.

Best regards
Andrej Golovnin


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate 4.x, JTA(BMT) transactions no longer interchangeable with Hibernate transaction facade?

[Zachary Kurey]

Following up with a clarification.  After looking at this again it
doesn't look like the Session path has this problem.  Instead the
EntityManager path of:
1.  start a JTA transaction programmatically
2.  check there is a current session
associated(SessionFactory.getCurrentSession()).  I only mention this
since the session I get with currentSession is not the same session
the produced entitymanager uses.
3.  call entityManagerFactory.createEntityManager()
4.  try to execute some JPA
query(entityManager.createQuery().executeUpdate()), and I get a
TransactionRequired Exception.

Specifically I'm looking at the EntityManager path of:
AbstractQueryImpl->executeUpdate->AbstractEntityManagerImpl->isTransactionInProgress->SessionImpl.isTransactionInProgress->TransactionCoordinatorImpl->JtaTransaction->isActive()

Which again the local status is not active.  When debugging I can also
see the underlying session is not the same session that I got from
currentSession().  Also before local status is checked I see the path
of 
SessionImpl->checkTransactionStatus->Coordinator.pulse()->attemptToRegisterJtaSync
is executed.  But transactionContext.autoJoinTransaction is false, so
the user transaction is never looked up.

It seems off to me that the entityManager produced after I started the
transaction is using a different underlying Session.  Is that correct
or not correct?

Again something seems broken or incredibly non-obvious here,
especially since this worked in 3.x.  Would love some feedback, but
until then I'm going to start boiling this into a testcase so its
really clear what my expectations are.

ZK

On Wed, May 9, 2012 at 10:47 AM, Zachary Kurey  wrote:
> Hi all,
>
> Am I correct in my interpretation that Hibernate 4 no longer supports
> interchangeably being able to use either the Hibernate transaction
> facade(session.beginTransaction) vs. UserTransaction or CMT?
>
> I say this because it appears that I always must call
> session.beginTransaction() when configured to use
> JTATransactionFactory, in order to have JtaTransaction->local status
> of active.  If local status is not active Hibernate makes no attempt
> to check the provided JtaPlatform if there is a user transaction in
> process and blows up whenever trying to execute any changes to the db.
>
> In 3.x this worked fine since
> JTATransactionFactory->isTransactionInProgress always tried to find
> the configured transaction manager and checked the transaction status
> properly.  But in 4.x I'm not seeing how local status gets set to
> active to prevent a blow up unless I both call userTransaction.begin()
> AND session.beginTransaction()...  The same problems exist when
> interacting through the EntityManager API.
>
> Even in the ManagedDrivingTest it looks like it is assumed that the
> client will call session.beginTransaction() after either a CMT or BMT
> has been started.  I would cut over to using the Hibernate facade
> exclusively, but now it throws 'nested transactions not supported' if
> beginTransaction is invoked multiple times.  The Spring
> PlatformTransactionManager API deals with multiple layered invocations
> more gracefully, so I've mostly used that in the past for programmatic
> transaction management.  But regardless, looking at the source there
> seems to be a new requirement to always have
> session.beginTransaction() invoked in application code.
>
> I've spent days trying to figure out if I've made a configuration
> mistake, and at this point I'm at the conclusion that either Hibernate
> behavior in this area was intentionally changed, or that this is a
> bug.  If its a bug it would probably break a lot of apps upgrading
> from 3.x to 4.x that use programmatically controlled transactions.  So
> I thought I'd just reach out on the mailing list for clarification, or
> to have an obvious misconfiguration or misunderstanding corrected.
>
> For more info on my JTA config there is a forum post I made that is
> unrelated(realized my error on that topic) here:
> https://forum.hibernate.org/viewtopic.php?p=2454363
>
> Thanks,
> Zach

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Memory consumption

[Andrej Golovnin]

Hi all,

I have today deployed our application for the first time
on JBoss 7 with the latest Hibernate and Hibernate Search versions.
And I was totally shocked when I saw the memory consumption.

I have created two screen shots from the memory dumps. The screen shots
are attached to this mail. Please take a look at them. The screen shot
names contains version numbers of the used Hibernate and Hibernate Search
frameworks. The memory dumps were created for one and the same
application version. I can't believe that the latest versions require nearly
twice as much memory as the old versions to perform the same tasks.
What's happen?

Is this a known problem? Do you have any plans to change this situation,
e.g. to work on reducing memory consumption? Or maybe you already 
started to work on this problem?

We have been running our application with 768MB for max heap size and
serving hundreds of users. And now using the same memory settings I can
just deploy the application. :-(

Best regards
Andrej Golovnin

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Memory consumption

[Andrej Golovnin]

Hi,

it seems that screen shots were stripped by the mailing list software.
I have uploaded them to flickr. Here are the links:

http://www.flickr.com/photos/78207256@N07/7166944408/in/photostream
http://www.flickr.com/photos/78207256@N07/7166945108/in/photostream

Best regards
Andrej Golovnin

On 09.05.2012, at 22:35, Andrej Golovnin wrote:

> Hi all,
> 
> I have today deployed our application for the first time
> on JBoss 7 with the latest Hibernate and Hibernate Search versions.
> And I was totally shocked when I saw the memory consumption.
> 
> I have created two screen shots from the memory dumps. The screen shots
> are attached to this mail. Please take a look at them. The screen shot
> names contains version numbers of the used Hibernate and Hibernate Search
> frameworks. The memory dumps were created for one and the same
> application version. I can't believe that the latest versions require nearly
> twice as much memory as the old versions to perform the same tasks.
> What's happen?
> 
> Is this a known problem? Do you have any plans to change this situation,
> e.g. to work on reducing memory consumption? Or maybe you already 
> started to work on this problem?
> 
> We have been running our application with 768MB for max heap size and
> serving hundreds of users. And now using the same memory settings I can
> just deploy the application. :-(
> 
> Best regards
> Andrej Golovnin
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Memory consumption

[Scott Marlow]

This sounds related to the discussion here 
https://community.jboss.org/message/729224#729224.

How many persistence units do you have defined in the application?  Can 
you get a list of files in the deployment (e.g. run "jar tf 
Appname.?ar") and show us the files.

On 05/09/2012 04:58 PM, Andrej Golovnin wrote:
> Hi,
>
> it seems that screen shots were stripped by the mailing list software.
> I have uploaded them to flickr. Here are the links:
>
> http://www.flickr.com/photos/78207256@N07/7166944408/in/photostream
> http://www.flickr.com/photos/78207256@N07/7166945108/in/photostream
>
> Best regards
> Andrej Golovnin
>
> On 09.05.2012, at 22:35, Andrej Golovnin wrote:
>
>> Hi all,
>>
>> I have today deployed our application for the first time
>> on JBoss 7 with the latest Hibernate and Hibernate Search versions.
>> And I was totally shocked when I saw the memory consumption.
>>
>> I have created two screen shots from the memory dumps. The screen shots
>> are attached to this mail. Please take a look at them. The screen shot
>> names contains version numbers of the used Hibernate and Hibernate Search
>> frameworks. The memory dumps were created for one and the same
>> application version. I can't believe that the latest versions require nearly
>> twice as much memory as the old versions to perform the same tasks.
>> What's happen?
>>
>> Is this a known problem? Do you have any plans to change this situation,
>> e.g. to work on reducing memory consumption? Or maybe you already
>> started to work on this problem?
>>
>> We have been running our application with 768MB for max heap size and
>> serving hundreds of users. And now using the same memory settings I can
>> just deploy the application. :-(
>>
>> Best regards
>> Andrej Golovnin
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [OGM] "How to setup OGM" Wiki page

[Guillaume SCHEIBEL]

Hi everyone,

I read this page
on
the wiki and there is this snippet :


   org.hibernate.ogm
   hibernate-ogm-core
   3.0.0.Alpha1


Shouldn't be updated with the current version (4.0.0-SNAPSHOT) ?

Cheers,
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HSEARCH] Proposal to change the default value of Field#norms()

[Sanne Grinovero]

On 9 May 2012 21:04, Andrej Golovnin  wrote:
> Hi Emmanuel,
>
>> Can you open a JIRA issue to clarify this in 
>> http://docs.jboss.org/hibernate/search/4.1/reference/en-US/html_single/#basic-mapping
>>  ?
>> Even better, can you propose the change as a GitHub pull request? :)
>
> Sure. :-)
>
>>>
>>> @Field(boost=@Boost(1.2f), norms = Norms.NO)
>>> private String description;
>>>
>>> Would I see a warning or maybe an error message from Hibernate Search?
>>> Does make such combination sense?
>>
>> I don't think we raise an exception, we should do something indeed. Do you 
>> want to open the JIRA and possibly provide a patch via a GitHub pull request?
>
> OK, I will do that. But creating patch will take some time.
>
>>> Btw Is it possible that OIDs added to index by IndexedEmbedded have
>>> norms? Luke shows me it in two different indexes. Could someone
>>> else please verify it? If it is the case, it would be nice if Hibernate 
>>> Search
>>> would have the same behavior for OIDs added to index either
>>> by DocumentId or by IndexedEmbedded, e.g. index them with
>>> NOT_ANALYZED_NO_NORMS.
>>
>> I am not following you. What's an OID.
>
> Suppose you have following classes:
>
> @Entity
> public PostalAddress {
>
>    @Id
>    private String OID;
>    .
> }
>
> @Entity
> @Indexed
> public Partner {
>
>    @Id
>    private String OID;
>
>    @OneToOne
>    @IndexEmbedded(depth = 1)
>    private PostalAddress defaultAddress;
>   
> }
>
> The Lucene document for Partner would contain the field
> OID from Partner indexed with NOT_ANALYZED_NO_NORMS
> and it will contain also the field "defaultAddress.OID". But the
> field "defaultAddress.OID" would have norms. This is what I see
> at least with Luke in my indexes. I think the field "defaultAddress.OID"
> should be also indexed with NOT_ANALYZED_NO_NORMS.

You're right. In fact there was a different proposal about not
indexing  "defaultAddress.OID" at all or optionally, but while that
caused some discussions and action is still unclear, let's at least
omit norms as they are definitely not needed nor expected for such a
field.. another JIRA please?

Regards,
Sanne

>
> Best regards
> Andrej Golovnin
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HV] Implementing method validation (was "HV-562")

[Gunnar Morling]

Hi Hardy,

nice post on the release, this should get started everyone with 4.3.
And we can finally focus on HV 5 :)

>> I'm looking forward to implementing the new API, this should be
>> fun :) I feel that it should be possible to split the work into
>> independent chunks which we can tackle in parallel.
>
> That sounds good. In a first cut we might be able to just try to compile the 
> latest BV SNAPSHOT and introduce the missing
> methods by introducing placeholders. Once the existing build passes again we 
> can already push a SNAPSHOT and start
> filling in the gaps.

I've created a branch for method validation [1], bumped the dependency
to the BV API to 1.1.Alpha1 and applied the minimal changes required
to get rid of any compilation errors (added
UnsupportedOperationExceptions within the new methods). I've also
added "TODO HV-571" markers everywhere, so we can't forget everything
:)

Regarding the actual implementation, I think there are two large
blocks, which might be addressed in parallel: a) implementing the new
validation methods and b) implementing the extensions to the meta data
API (plus some other things such as changes to ConfigurationImpl
etc.).

If we decide to work on this in parallel, we might push the HV-571
feature branch to the upstream repo, integrate the method validation
work there and push it later on in one go to master.

WDYT, would that make sense?

--Gunnar

[1] https://github.com/gunnarmorling/hibernate-validator/compare/HV-571
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Memory consumption

[Sanne Grinovero]

Hi Andrej,

Hibernate Search at version 3.0.1 did a small fraction of what it does
today so I would expect indeed it to take a bit more memory but no I
wasn't aware of significant increases.

Looking just at the Search-related figures however it looks like
memory consumption is significantly *lower* than the old times? That's
not really expected, so I'm assuming that some of the memory used by
SessionFactoryImpl, Configuration, JavaReflectionManager is actually
holding to references which are Search related.

In short, it would help us a lot if you could open the details and
explore a bit around the references to understand where things might
have done out of control :-(

Among other improvements in Search, it does now keep open references
to both IndexReaders and IndexWriters, and both consume quite some
memory as they aggressively cache metadata from the indexes. This is a
good thing, as otherwise you would be using this same memory anyway,
but per-hit causing a lot of work for GC but still showing better
figures for the older version as the memory is not really "reserved"..
could you compare them as well by disabling such features in Search ?
Same for FieldCaches and other stuff..

in practice:
 - hibernate.search.​default.​exclusive_index_use = false
 - hibernate.search.default.reader.strategy = not-shared
 - @CacheFromIndex <- all explicitly disabled since it defaults to "class"
 - avoid filter caching

I guess you're comparing them without any application or configuration
changes, still you would need to make these configuration changes to
make the comparison fair as these features didn't exist at the time
and are now enabled by default.
This will disable some benefits you get from latest Search, but not
all of them.. just curious to see if it gets us into more reasonable
limits.

Regards,
Sanne

On 9 May 2012 22:11, Scott Marlow  wrote:
> This sounds related to the discussion here
> https://community.jboss.org/message/729224#729224.
>
> How many persistence units do you have defined in the application?  Can
> you get a list of files in the deployment (e.g. run "jar tf
> Appname.?ar") and show us the files.
>
> On 05/09/2012 04:58 PM, Andrej Golovnin wrote:
>> Hi,
>>
>> it seems that screen shots were stripped by the mailing list software.
>> I have uploaded them to flickr. Here are the links:
>>
>> http://www.flickr.com/photos/78207256@N07/7166944408/in/photostream
>> http://www.flickr.com/photos/78207256@N07/7166945108/in/photostream
>>
>> Best regards
>> Andrej Golovnin
>>
>> On 09.05.2012, at 22:35, Andrej Golovnin wrote:
>>
>>> Hi all,
>>>
>>> I have today deployed our application for the first time
>>> on JBoss 7 with the latest Hibernate and Hibernate Search versions.
>>> And I was totally shocked when I saw the memory consumption.
>>>
>>> I have created two screen shots from the memory dumps. The screen shots
>>> are attached to this mail. Please take a look at them. The screen shot
>>> names contains version numbers of the used Hibernate and Hibernate Search
>>> frameworks. The memory dumps were created for one and the same
>>> application version. I can't believe that the latest versions require nearly
>>> twice as much memory as the old versions to perform the same tasks.
>>> What's happen?
>>>
>>> Is this a known problem? Do you have any plans to change this situation,
>>> e.g. to work on reducing memory consumption? Or maybe you already
>>> started to work on this problem?
>>>
>>> We have been running our application with 768MB for max heap size and
>>> serving hundreds of users. And now using the same memory settings I can
>>> just deploy the application. :-(
>>>
>>> Best regards
>>> Andrej Golovnin
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with Properties of Embeddable Classes and Type Registry

[Chris Pheby]

Hi Steve,

Thanks for your reply. I decided to dig deeper and find the fix.

The problem is that the type is being cached inside the Component class.

I created the Jira issue at https://hibernate.onjira.com/browse/HHH-7310
I also created a pull request for a test and the fix at 
https://github.com/hibernate/hibernate-orm/pull/335

Regards Chris

-Original Message-
From: Steve Ebersole [mailto:steven.ebers...@gmail.com] On Behalf Of Steve 
Ebersole
Sent: 01 May 2012 15:25
To: Chris Pheby
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Problem with Properties of Embeddable Classes and 
Type Registry

Hey Chris,

That is not the expected behavior.  Myabe just an oversight in how components 
(embeddables) are handled?  If that is the behavior you see, I would consider 
that a bug.  Please create a JIRA and attach a test case as outlined @ 
http://hibernate.org/issuetracker

If you want to give solving the problem a go, have a look @ 
https://github.com/hibernate/hibernate-orm/wiki/Contributing-Code


On Tue 01 May 2012 05:02:07 AM CDT, Chris Pheby wrote:
> Hello,
>
> The new type registry capability in Hibernate 4 and above is really useful. I 
> have implemented an integrator that autoregisters some types, however what I 
> have found is that whilst this works perfectly, the registered types are not 
> being resolved correctly when they are used within @Embeddable classes.
>
> Is this the expected behaviour?
>
> I have tried debugging through the sources and it looks like the 
> SessionFactory's TypeResolver is not used in the case of properties of such 
> classes. See the comments at 
> http://blog.jadira.co.uk/blog/2012/1/19/release-jadira-usertype-300cr1-with-support-for-joda-money-0.html#comments.
>
> Thanks Chris
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
st...@hibernate.org
http://hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [SEARCH] @Indexed on abstract classes

[Guillaume Smet]

Hi Search team,

I have this question for a long time but, this time, having 30 (and
growing) indexed entities inheriting from an abstract class, I thought
I might as well ask about it...

Is there any reason why we can't set the @Indexed annotation on the
abstract class to get all the implementations indexed in their
separate indexes? This way, I wouldn't have to put the annotation on
each implementation and think about adding it each time I extend this
abstract class.

Another painful things that beats me yesterday is that I cannot do:
searchFactory.buildQueryBuilder().forEntity(MyAbstractEntity.class).get();
to build Lucene queries based on the common indexed fields of the
abstract class: I'm forced to use one of the concrete implementation
(and apart that it's not that nice, I'm not that confident I can
choose one that will never be removed from the code base).

Thanks for your feedback.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM 4.1.3 release announcement?

[Guillaume Smet]

Hi,

While 4.1.3 was released some time ago, I haven't seen any
announcement for that on either the Hibernate website or the list.

Is there a reason for that? It contains very valuable bugfixes
(especially on the NaturalId front) that might be of interest for a
lot of users, which are not as JIRA addicted as I am.

I thought it might be an overlook. Feel free to ignore this message if
you have better things to do :).

Btw, thanks for this release which fixes all the problems we had with
the new NaturalId API/cache on our project.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev