Changes to the ORM Travis configuration
by Guillaume Smet
Hi,
I committed a few changes to the ORM Travis configuration to hopefully make
the builds more stable - we had a lot of failures due to timeouts.
As Gradle can spend a lot of time on a specific step without any output,
the ORM jobs often timed out.
I added a travis_wait 45 to allow the Gradle command to run for 45 minutes.
It should be used by the new PRs as soon as you're based on current master.
There is one drawback: you only see the command output when it's either
finished or timed out but I thought you are probably not spending your time
looking at the jobs in progress.
Hopefully, it will help.
--
Guillaume
8 years
Scheduling issues
by Steve Ebersole
I am trying to determine where we are with 5.3 Final. So I look in Jira
and the original 4 issues I added to Final (mainly verification tasks) have
jumped to 19. This makes it impossible to plan. So please, if you are not
actively working on an issue or are not planning on finishing it within a
few days do not schedule it for 5.3.0.Final. Feel free to create a 5.3.1
and schedule it there *if* you are planning on working on it. If you are
not planning on working on it do not schedule it.
Thanks
8 years
Re: [hibernate-dev] JDK 11 Early Access build 12 available
by Sanne Grinovero
Hi Dalibor!
specifically about the version parsing we have hit some in Apache Karaf:
- https://issues.apache.org/jira/browse/KARAF-5725
I previously reported the same for JDK10:
- https://issues.apache.org/jira/browse/KARAF-5641
(the JDK10 related issue was resolved but it needs further changes to
deal with JDK11)
Even solving those it's a problem for OSGi testing as e.g. Pax Exam,
the integration testing tool we use to test with Karaf, was not
updated to match the latest Karaf issues. So to summarize currently
I'm not sure how to test anything on OSGi, we probably should look at
alternative integration testing tools.
Gradle is affected by the "version parsing" issue as well; it's fixed
now but wasn't released yet:
- https://github.com/gradle/gradle/issues/4515
I've tested the nightly builds and it's ok, however even the nightly
builds only aim at JDK10 compatibility; JDK11 is scheduled for future
work.
We used the nightlies to test on both JDK10 and JDK11 and it seems to
work quite well, yet I have several other failures which I believe are
not related to Gradle nor specifically to the version format, so it's
all a bit premature to evaluate.
We will of course report issues to Gradle and/or others when things get clearer.
Next, coming from our Maven projects we have Surefire also chocking on
the version:
- https://issues.apache.org/jira/browse/SUREFIRE-1439
this one was worrying me most as it took a long time to be fixed; as
you can see I reported it back in November 2017, during our JDK10
early access testing period.
Ironically some of those issues won't be triggered by the JDK11 final
release as the "-ea" part is the problem trigger, so maybe it will be
fine but it's having me disable large portions of our testsuites.
I guess the fact that JDK10 is no longer flagged as "ea" is what is
causing most of these issues to get reported in pairs: some libraries
fixed without the postfix first and then need a second patch when
people start looking at -ea versions; may I suggest to not change it
further for the LTS, or maybe even consider an enhancement: provide an
alternative to "-version" meant to facilitate machine parsing. Having
a prefix of two "--" while at it :)
I'll spare you details of the issues not related to versions at this
stage, we still have much work to do.
Thanks and regards,
Sanne
On 9 May 2018 at 19:30, dalibor topic <dalibor.topic(a)oracle.com> wrote:
> Hi Sanne,
>
> thank you for testing! Do you have a few URLs to share about the 11-ea
> version parsing issues you've seen with other tools?
>
> cheers,
> dalibor topic
>
>
> On 08.05.2018 11:14, Sanne Grinovero wrote:
>>
>> Hi Rory,
>>
>> thanks for the regular updates!
>>
>> Unfortunately many tools we need are still unable to run properly on
>> JDK11 so I can't run our comprehensive tests.
>>
>> For the record, a common issue seems to be the inability to parse the
>> '11-ea' version number.
>>
>> The few modules I can run "manually" in isolation didn't highlight any
>> specific problem with Hibernate libraries so far, but such testing has
>> been quite limited. I hope to be able to tell you more soon.
>>
>> Regards,
>> Sanne
>>
>>
>>
>>
>> On 8 May 2018 at 09:05, Rory O'Donnell <rory.odonnell(a)oracle.com> wrote:
>>>
>>> Hi Sanne,
>>>
>>>
>>> **JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses,
>>> is now available at **http://jdk.java.net/11**. **
>>> *
>>>
>>> * Newly approved Schedule, status & features
>>> o http://openjdk.java.net/projects/jdk/11/
>>> * Release Notes:
>>> o http://jdk.java.net/11/release-notes
>>> * Summary of changes
>>> o
>>> https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>>>
>>> *Notable changes in JDK 11 EA builds since last email:*
>>>
>>> * Build 11 - see Release Notes for details.
>>> o JDK-8201315 : SelectableChannel.register may be invoked while a
>>> selection operation is in progress
>>> * Build 10 - see Release Notes for details.
>>> o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>>> o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms
>>> o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>>> * Build 9: - see Release Notes for details.
>>> o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>>> o JDK-8200458 : Readiness information previously recorded in
>>> SelectionKey ready set not preserved
>>>
>>> **
>>>
>>>
>>> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
>>> *
>>> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
>>> the JDK. As outlined in the JEP, the usefulness of this technology
>>> have diminishing returns, the components using them are being removed
>>> and connectivity speeds have improved by leaps and bounds,
>>> since its inception. Feedback appreciated via
>>> http://mail.openjdk.java.net/pipermail/jdk-dev
>>>
>>> Regards,
>>> Rory
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>>>
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA, Dublin,Ireland
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
8 years
Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3
by Sanne Grinovero
Hi Andrej,
you're right, I found the most interesting email from you now (reading
the whole thread) :
- http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html
I'm not sure why the discussion stopped, I'm sorry.
Let's try to fix it this time, to make sure of that we need a JIRA.
Someone created one? Guillaume?
summary:
- problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
- great results applying Andrej's
https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca...
- the patch could be improved today with Java8
-- I'd like to have some degree of upfront validation at boostrap still
-- hopefully explore an array based structure
-- do not extend CHM
-- ideally have no read barriers at all at runtime
Thanks,
Sanne
On 6 May 2018 at 22:03, Andrej Golovnin <andrej.golovnin(a)gmail.com> wrote:
> Hi,
>
>> So, I analyzed the dumps yesterday evening. The problem is real, meaning
>> his SessionFactory is consuming more than 1GB of memory for 600+ tables,
>> some with a lot of attributes. So for sure, the model is a big one, …
>
> No, it is still a small one. I work on a project with 2145 tables. And the SessionFactory
> consumes on production systems ca 300-400MB with Hibernate 5.2. I haven’t
> tested the project with Hibernate 5.3. But I doubt it would consume more memory.
> Except the Hibernate team broke something again.
>
>> but it
>> would be nice to be more gentle with this type of configuration. I don't
>> think it's something new to 5.3 though as it's not the first time we have
>> this type of reports.
>>
>>> From my observations, the problem mostly comes from:
>> LegacyBatchingEntityLoader
>> \_ loaders - EntityLoader
>> \_ staticLoadQuery - EntityLoadQueryDetails
>> \_ rootReturn - EntityReturnImpl
>>
>> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
>> MB.
>>
>> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
>> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
>> taking ~ 200 KB.
>>
>> We discussed some ideas yesterday with Steve.
>
> And I have discussed it with the Hibernate team 6 years ago:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html
>
> And my suggestion to create things lazily were ignored/rejected.
> And I have ignored the opinion of the Hibernate team and implemented
> my suggestions in my version of Hibernate and saved a lot of memory
> in my project.
>
> Btw. please ask the user whether he has a lot of abstract entity classes.
> When yes, then ask him if it would be possible to convert this entity classes
> to mapped supper-classes. This may help to reduce memory consumption too.
>
> Best regards,
> Andrej Golovnin
8 years
JPA XML ORM descriptors id-class and id
by Gail Badner
When an entity with an IdClass is mapped using XML ORM descriptors,
Hibernate requires the Id properties to be mapped as well, as in the
following example:
<entity class="Employee">
<table name="entityobject"/>
<id-class class="EmployeeId"/>
<attributes>
<id name="fname"/>
<id name="lname"/>
</attributes>
</entity>
If the <id> elements are not included, an exception is thrown:
"No identifier specified for entity: ..."
Should Hibernate require the <id> elements to be explicitly mapped, or
should it be able to determine this information by reflection from the
class configured by <id-class>?
Regards,
Gail
8 years
Hibernate Search 5.10.0.CR1 released!
by Guillaume Smet
Hi,
We just released the first release candidate of Hibernate Search 5.10 with
support for Hibernate ORM 5.3.0.CR2 (and thus JPA 2.2).
Test it and report any issues you might encounter!
Thanks.
--
Guillaume
8 years
JDK 11 Early Access build 12 available
by Rory O'Donnell
Hi Sanne,
**JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
*Notable changes in JDK 11 EA builds since last email:*
* Build 11 - see Release Notes for details.
o JDK-8201315 : SelectableChannel.register may be invoked while a
selection operation is in progress
* Build 10 - see Release Notes for details.
o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms
o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
* Build 9: - see Release Notes for details.
o JDK-8200152 : KerberosString uses UTF-8 encoding by default
o JDK-8200458 : Readiness information previously recorded in
SelectionKey ready set not preserved
**
*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed
and connectivity speeds have improved by leaps and bounds,
since its inception. Feedback appreciated via
http://mail.openjdk.java.net/pipermail/jdk-dev
Regards,
Rory
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
8 years
