Still an issue with Agroal when closing the pool
by Guillaume Smet
Hi Luis,
We talked at some point about a potential issue in Agroal, you said 1.3
should have all the known issues solved but apparently, there is still one
as we have transient test failures on ORM from time to time.
A good example is the following one:
http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-javassist/la...
(it's build #265, haven't found a way to get a stable URL from Jenkins)
The issue is in this test:
org.hibernate.test.agroal.AgroalTransactionIsolationConfigTest.testSettingIsolationAsName
.
And we have the following stacktrace when closing the pool:
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@189a0b8e
rejected from io.agroal.pool.util.PriorityScheduledExecutor@2ded5d2e[Shutting
down, pool size = 1, active threads = 0, queued tasks = 1, completed
tasks = 2]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622)
at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:46)
at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:35)
at io.agroal.pool.util.PriorityScheduledExecutor.shutdown(PriorityScheduledExecutor.java:67)
at io.agroal.pool.ConnectionPool.close(ConnectionPool.java:126)
at io.agroal.pool.DataSource.close(DataSource.java:54)
at org.hibernate.agroal.internal.AgroalConnectionProvider.stop(AgroalConnectionProvider.java:142)
at org.hibernate.testing.common.connections.BaseTransactionIsolationConfigTest.testSettingIsolationAsName(BaseTransactionIsolationConfigTest.java:101)
It happens once in a while. I already had the issue locally but lately I
only observed it on CI.
I suppose it won't be easy to get to the bottom of it but it would be nice
if we could get this fixed.
Thanks.
--
Guillaume
5 years, 10 months
JDK 12 enters Rampdown Phase Two
by Rory O'Donnell
Hi Sanne,
**OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at
: - jdk.java.net/12/*
* Per the JDK 12 schedule [1], we are now in Rampdown Phase Two.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
o Per the JDK Release Process [3] we now turn our focusto P1 and
P2 bugs.
**OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at
: - jdk.java.net/13/*
* These early-access, open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Release Notes:
o http://jdk.java.net/13/release-notes
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B3%22%3A%...>
Blog Updates from Java SE Product Management since last email.
* Oracle Java SE Releases FAQ [3]
* Oracle Java SE Support Roadmap [4]
Rgds,Rory
[1] http://openjdk.java.net/projects/jdk/12/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html
[3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq
[4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 11 months
Releasing 5.4.1.Final
by Guillaume Smet
Hi,
I'm in the process of releasing 5.4.1.Final, please don't push anything to
master.
Thanks.
5 years, 11 months
Chat migration - D minus 115 until the death of HipChat
by Yoann Rodiere
Hi,
TL;DR: please vote here if you don't want to end up having to use a chat
tool you don't like: https://doodle.com/poll/h6scc9bsh6a4ymre
HipChat Cloud will stop working on February 15th, 2019 [1]. We need to
choose an alternative before we have our back against the wall, so I'll try
to resurrect the conversation.
As a reminder, Stride is no longer an option: Atlassian cancelled the
project, and encourages users to migrate to Slack.
The discussed options so far were:
- *Moving back to IRC*. Aye: ?; nay: ?
Pros: simple as hell.
Cons: basic as hell; we won't keep the chat history.
- *Migrating to Slack* [6], as suggested by Atlassian [2]. Aye:
Christian B; Nay: ?
Pros: we will keep the chat history (I think).
Cons: not open-source; desktop client consumes a lot of resources.
- *Migrating to Zulip* [3]. Aye: Emmanuel, Yoann. Nay: Guillaume (kind
of).
Pros: Advanced conversation management thanks to the "topics" feature.
Cons: Complex to use because of the "topics" feature; we won't keep the
chat history (1).
- *Migrating to Gitter* [5] (we'll create different rooms, probably).
Aye: ?, Nay: ?
Pros: Users seem to actually go there, so we could have our "live
support" rooms next to our "internal discussion" rooms.
Cons: not open-source; we won't keep the chat history (1).
I created a poll based on the discussion we had on the thread
"[hibernate-dev] Stride". I think everyone had the time to suggest another
option.
Please vote here and now, or remain silent forever ;):
https://doodle.com/poll/h6scc9bsh6a4ymre
I'd suggest the following rules: if there's a single clear winner (a
platform that everyone would be happy with), we'll pick that one. If there
are multiple clear winners, whoever does the migration work will pick
what's easier to set up (taking into account the various integrations).
Otherwise, back to discussing it on this thread...
(1) There seems to be some work in progress on a migration tool from
HipChat to Zulip, but it doesn't seem to be ready yet [4]
[1]
https://www.atlassian.com/partnerships/slack/faq#faq-da2b66a1-53d3-4c4e-a...
[2] https://www.atlassian.com/partnerships/slack/migration
[3] https://hibernate.zulipchat.com/
[4] https://github.com/zulip/zulip/issues/10647
[5] https://gitter.im/hibernate/hibernate-orm
[6] https://slackdemo.com/
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
5 years, 11 months
Loggers
by Steve Ebersole
Yes, I know no one likes talking about logging. "Its not important", until
it is ;)
TLDR I am considering moving to using "module names" for logger names
instead of Class names even for DEBUG/TRACE logging and see if anyone had
strong arguments to not do this..
Full version---
For some time I have been moving to an approach of defining message
loggers[1] using a single contract per function or "module" - e.g.:
1. the second level caching module uses the dedicated message logger
`ConnectionPoolingLogger`
2. the ManagedBeanRegistry module uses the dedicated message logger
`BeansMessageLogger`
3. etc
Each of these define a dedicate instance instance they can use. E.g.
ConnectionPoolingLogger is defined as:
````
@MessageLogger( projectCode = "HHH" )
@ValidIdRange( min = 10001001, max = 10001500 )
public interface ConnectionPoolingLogger extends BasicLogger {
ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger(
ConnectionPoolingLogger.class,
"org.hibernate.orm.connections.pooling"
);
...
}
````
I won't get into all the whys I do this unless someone cares ;)
But I am contemplating doing the same for basic loggers so I wanted to ask
everyone else's opinion since this means a change in how you'd have to
configure logging for DEBUG/TRACE output. Usually you'd use the Class name
as the logger name and use that to control logging in the back-end (log4j,
etc). If I do this, you'd have to instead use the module name.
There are quite a few reasons I am considering this, including all of the
reasons I did it for message loggers in the first place. If I am
debugging the loading of a collection or an entity, today I'd have to know
all the packages involved (there is no common root name) and list them in
my log4j.properties; that is because the process is ultimately handled by
delegates or helpers in many different packages (`org.hibernate.loader`,
`org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be
nice to just be able to say `org.hibernate.loading` or
`org.hibernate.loading.entity` or `org.hibernate.loading.collection` or ...
for a number of reasons:
1. When we need to see logging from someone it is a lot easier to tell
the module name(s) you need enabled as opposed a list of package and class
names.
2. When running JPA TCK it is essentially impossible to attach debugger
to step through code when debugging a failure - you have to rely on
debugging through output. *Well that used to be the case, but the
latest TCK broke logging to STDOUT somehow so we ended up having to try and
reproduce the failure in our testsuite - so then it does not matter either
way ;)*
3. Easier to document -
http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Loggi...
Thoughts?
[1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which
we use for user-focused log messages. Should always be logged at >= INFO
[2]
[3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for
developer-focused log messages (for debugging). Should always be logged at
DEBUG or TRACE
5 years, 11 months
[ORM] Reducing startup log verbosity
by Guillaume Smet
Hi,
Got a report from a fellow Red Hatter complaining about our logging
verbosity being so 2004 and, well, I must admit I tend to agree.
This is from a launch on a simple PostgreSQL app. I added some comments
inline.
Note that it might seem like wasting our time but I would like to improve
the user experience in some contexts - happy to discuss the rationale
behing this discussion privately if needed.
[o.h.Version] (build-) HHH000412: Hibernate Core {5.4.0.Final}
-> this one is a product requirement so let's keep it as is for now,
hopefully, we will have a global solution for that at some point
[o.h.c.Environment] (build-) HHH000206: hibernate.properties not found
-> I think we should use DEBUG here, framework nowadays rely on their own
config injection mechanisms
[o.h.b.e.s.Enhancer] (pool-2-thread-6) Enhancing [jpa.SequencedAddress] as
Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-10) Enhancing [jpa.WorkAddress] as
Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-1) Enhancing [jpa.Address] as Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-8) Extended enhancement of [jpa.Animal]
[o.h.b.e.s.Enhancer] (pool-2-thread-13) Enhancing [jpa.Human] as
MappedSuperclass
[o.h.b.e.s.Enhancer] (pool-2-thread-16) Enhancing [jpa.Person] as Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-5) Enhancing [jpa.Customer] as Entity
-> I would vote for using DEBUG. Let's imagine a 250 entities model and I
think we can agree we don't want it to be logged by default.
[o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [
name: templatePU
...]
-> so, first, I would make this one a one liner as we apparently didn't add
any other properties. I think it was done to mimic the DEBUG output but I
don't see any value to having it on several lines.
And, frankly, I think I would get rid of it altogether and only log
something at debug level.
[o.h.a.c.Version] (main) HCANN000001: Hibernate Commons Annotations
{5.1.0.Final}
-> version, can't touch it for now.
[o.h.d.Dialect] (main) HHH000400: Using dialect:
org.hibernate.dialect.PostgreSQL95Dialect
-> wondering if it has any value to log the dialect? I mean if you don't
use the right one, you will definitely have some issues.
[o.h.e.j.e.i.LobCreatorBuilderImpl] (main) HHH000422: Disabling contextual
LOB creation as connection was null
-> I would move that to DEBUG.
[o.h.t.BasicTypeRegistry] (main) HHH000270: Type registration
[java.util.UUID] overrides previous :
org.hibernate.type.UUIDBinaryType@7e8dcdaa
-> as I understand it, we will always have this message at startup when
using PostgreSQL. I think we should make it DEBUG too. Or find another
solution for this specific case but having it logged on each PostgreSQL app
is definitely a bad thing.
[o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform
implementation:
[org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform]
-> This one, I don't know. It's probably important to know that JTA is
properly configured but I'm not terribly excited about keeping it. Thoughts?
Maybe one solution could be to have all these ones tied to a
"org.hibernate.bootstrap" logger and thus have the ability to enable them
in one go.
I heard you made nice things in 6 about logging but I would like to improve
the situation in the stable version.
I would like to move quickly on this and hopefully integrate it in the
upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just
work on the easy ones, that would still improve the situation.
Thanks!
--
Guillaume
5 years, 11 months
Planning an ORM maintenance release: 5.4.1.Final
by Sanne Grinovero
Hi all,
I plan to tag a maintenance release of Hibernate ORM 5.4.1.Final on
Thursday, to be published and distributed Friday.
Please try to polish and merge any work you might want included, or
yell at me if you object with the timing?
And of course, as usual:
don't freak out if your work won't be ready on time; there will be
more releases.
Thanks,
Sanne
5 years, 11 months
