PTO
by andrea boriero
This afternoon I will be on PTO. Sorry for the late notice but it was due
to an unexpected event.
Andrea
7 years, 11 months
Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3
by Guillaume Smet
Hi Andrej,
On Sun, May 6, 2018 at 11:03 PM, Andrej Golovnin <andrej.golovnin(a)gmail.com>
wrote:
> > 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
>
It's not only the number of tables but also the number of columns per
table. The table I take as an example in my tests has 200+ columns, which
definitely doesn't help.
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.
>
See, we are improving.
I see a lot of conjectures in the thread but we should have analyzed the
memory dump more closely to understand exactly what was going on.
I think it would have led to a different outcome.
> 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.
>
Yeah, first, I would like to see if we can improve the situation by
changing the ORM code. I'm more for us improving the situation globally
rather than tweaking the model of each user.
If we can come up with some patches, it would be nice if you could test
them with your workload.
--
Guillaume
7 years, 11 months
Small change to the ORM Travis configuration
by Guillaume Smet
Hi,
The Travis cache behaves this way:
- try to get a cache specific to the PR
- then try to get a cache for master
- if none found, start without cache
The ORM Travis build was configured to not build the branches so master was
never build thus each PR starts with an empty cache (but subsequent pushes
to the same PR will use the PR cache).
I enabled the build for branches (Settings > Build pushed branches) so that
you have a cache for master. This should speed up the builds significantly.
--
Guillaume
7 years, 11 months
Releases and CI setup
by Guillaume Smet
Hi,
So, as expected, I'm not very happy with the new CI setup when doing
releases.
The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1,
5,2, master-h2, master-check) which takes all the slave bandwidth we have.
Note that I'm talking of ORM because it's where the issue is the most
prominent but I'm pretty sure I would have the same issue with HV,
considering we now have quite a few maintenance branches, except that the
HV builds are faster.
So I would say:
- either we fix the issue we have with all the branches being tested for
each commit that we discussed numerous times
- or we need a mechanism to start specific slaves for releases - but I'm
not sure it's fast enough tbh
Because it's really annoying. Especially when you have to run your release
job 3 times in a row due to SF.net issues...
Releasing is already a tedious process, let's not make it even more tedious.
(yeah I know it's not the first time I complain about it but it's really
worse than it was before)
--
Guillaume
7 years, 11 months
HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
by Sanne Grinovero
Picking automatic module names for Hibernate Search isn't going to be
straight-forward as our two main jars (hibernate-search-engine &
hibernate-search-orm) suffer from split package among them.
We can't really fix the split package problem without breaking all
users, so if we want to consider that, we can debate it but that will
need to happen at another round as we're doing a minor release, so
let's focus on:
# Which names to pick
# Should we pick the names at all
# Which modules should have a name
For a great background on the possible strategies and pitfalls I
recommend reading Stephen Colebourne's blog on this subject [1].
He persuaded me there are good reasons to use the "reverse DNS, the
top level package", however since we have the split package problem we
can't simply go with that.
Still, we can respect the principles he recommends with a small
variation. It's fair to assume that the `org.hibernate.search` prefix
is "ours"; since the nature of the suggestion is focused on making
sure there are no misunderstandings in the community about which names
you can choose - as there is no central authority making sure module
names aren't clashing - we should be fine within Hibernate projects
with any `org.hibernate.X` prefix, as long as we coordinate and reach
an agreement on this list.
So, I propose we use:
Engine module:
- org.hibernate.search.engine
ORM integration module:
- org.hibernate.search.orm
JGroups, JMS backends:
[ no automatic module name ? Excepting some "guidelines" in the JMS
module, these are not public API so nobody would benefit from it -
also we think we might want to phase out the name "backend" in the
future ]
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
- org.hibernate.search.elasticsearch
Elasticsearch / AWS security integration:
[ no automatic module name: no public API ]
Serialization / Avro
[ no automatic module name: no public API ]
WDYT?
We could also pick names for the ones which I've listed as "no public
API" but I see no point: as we're only assigning an "Automatic Module
Name" we won't be able to explicitly state that the other modules
depend on these. So nobody will use them, and things are a bit in flux
anyway in this area because of Hibernate Search 6 plans.
Another optional altogether: since we have split packages which we'll
have to resolve before we can actually transform these into fully
fledged modules, I think an acceptable position is also to say we
won't be publishing any automatic module name yet. Personally I'm
inclined to go with the names suggested above, at least some others
can start making baby steps, even if it's not all there.
# What I don't like:
For one, that the typical application will need to import both
`org.hibernate.search.engine` and `org.hibernate.search.orm`, and
likely more as well (e.g. Elasticsearch API, Lucene API module is
coming, ..).
Maybe similar to BOM's today we could publish a module which
statically imports multiple of these, that could be nicer to use but
we risk needing to publish (and document) one for each of a selection
of combinations. So let's not start with such things yet.
Thanks,
Sanne
[1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
7 years, 11 months
Depending on JAXB / JDK11 compatibility
by Sanne Grinovero
With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
it as a runtime dependency.
Java 9 users have been suggested to use the JVM option "--add-modules
java.xml.bind" to avoid the JVM hiding the JAXB library from
classpath.
With Java 11 the java.xml.bind is no longer available; what should we
suggest to users?
Should we list it as an explicit dependency in the released pom files?
Thanks,
Sanne
7 years, 11 months
