[JIRA] (HHH-13987) LocalDate is affected by timezone conversions
by Vlad Mihalcea (JIRA)
Vlad Mihalcea ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMWUyYWY2Y2Fm... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiMWUyYW... ) HHH-13987 ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiMWUyYW... ) LocalDate is affected by timezone conversions ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiMWUyYW... )
Change By: Vlad Mihalcea ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
If we set the default MySQL time zone to UTC:
{code:java}
default_time_zone='+00:00'
{code}
And use the following mapping:
{code:java}
@Entity(name = "UserAccount")
@Table(name = "user_account")
public static class UserAccount {
@Id
private Long id;
@Column(name = "first_name", length = 50)
private String firstName;
@Column(name = "last_name", length = 50)
private String lastName;
@Column(name = "subscribed_on")
private LocalDate subscribedOn;
public Long getId() {
return id;
}
public UserAccount setId(Long id) {
this.id = id;
return this;
}
public String getFirstName() {
return firstName;
}
public UserAccount setFirstName(String firstName) {
this.firstName = firstName;
return this;
}
public String getLastName() {
return lastName;
}
public UserAccount setLastName(String lastName) {
this.lastName = lastName;
return this;
}
public LocalDate getSubscribedOn() {
return subscribedOn;
}
public UserAccount setSubscribedOn(LocalDate subscribedOn) {
this.subscribedOn = subscribedOn;
return this;
}
}
{code}
When persisting the following entity:
{code:java}
UserAccount user = new UserAccount()
.setId(1L)
.setFirstName("Vlad")
.setLastName("Mihalcea")
.setSubscribedOn(
LocalDate.of(
2013, 9, 29
)
);
entityManager.persist(user);
{code}
Hibernate generates the following SQL INSERT statement:
insert into user_account (first_name, last_name, subscribed_on, id) values (?, ?, ?, ?)"], Params: \ [(Vlad, Mihalcea, 2013-09-29, 1)
However, when fetching it:
{code:java}
assertEquals(
LocalDate.of(
2013, 9, 29
),
userAccount.getSubscribedOn()
);
{code}
We get the following failure message:
{code:java}
Expected :2013-09-29
Actual :2013-09-28
{code}
This is because in the database the following row was inserted:
{code:java}
| id | first_name | last_name | subscribed_on |
|----|------------|-----------|---------------|
| 1 | Vlad | Mihalcea | 28-09-13 |
{code}
Setting the timezone property does not fix also emulates the problem even if the server timezone is not set :
{code:java}
@Override
protected void additionalProperties(Properties properties) {
properties.setProperty(AvailableSettings.JDBC_TIME_ZONE, "UTC");
}
{code}
because this is I think java.sql.Date and LocalDate should not taken into consideration be affected by `LocalDateType` timezone conversions as they shouldn’t behave like Timestamp types that contain time information.
( https://hibernate.atlassian.net/browse/HHH-13987#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13987#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100125- sha1:29f7b81 )
4 years, 5 months
[JIRA] (HHH-13987) LocalDate does not use the `hibernate.jdbc.time_zone` setting so conversion issues can occur
by Vlad Mihalcea (JIRA)
Vlad Mihalcea ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiODZiZTY1M2Q1... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiODZiZT... ) HHH-13987 ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiODZiZT... ) LocalDate does not use the `hibernate.jdbc.time_zone` setting so conversion issues can occur ( https://hibernate.atlassian.net/browse/HHH-13987?atlOrigin=eyJpIjoiODZiZT... )
Issue Type: Bug Assignee: Unassigned Components: hibernate-core Created: 28/Apr/2020 06:23 AM Priority: Major Reporter: Vlad Mihalcea ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
If we set the default MySQL time zone to UTC:
default_time_zone= '+00:00'
And use the following mapping:
@Entity(name = "UserAccount" )
@Table(name = "user_account" )
public static class UserAccount {
@Id
private Long id;
@Column(name = "first_name" , length = 50)
private String firstName;
@Column(name = "last_name" , length = 50)
private String lastName;
@Column(name = "subscribed_on" )
private LocalDate subscribedOn;
public Long getId() {
return id;
}
public UserAccount setId( Long id) {
this.id = id;
return this ;
}
public String getFirstName() {
return firstName;
}
public UserAccount setFirstName( String firstName) {
this.firstName = firstName;
return this ;
}
public String getLastName() {
return lastName;
}
public UserAccount setLastName( String lastName) {
this.lastName = lastName;
return this ;
}
public LocalDate getSubscribedOn() {
return subscribedOn;
}
public UserAccount setSubscribedOn(LocalDate subscribedOn) {
this.subscribedOn = subscribedOn;
return this ;
}
}
When persisting the following entity:
UserAccount user = new UserAccount()
.setId(1L)
.setFirstName( "Vlad" )
.setLastName( "Mihalcea" )
.setSubscribedOn(
LocalDate.of(
2013, 9, 29
)
);
entityManager.persist(user);
Hibernate generates the following SQL INSERT statement:
insert into user_account (first_name, last_name, subscribed_on, id) values (?, ?, ?, ?)"], Params:[(Vlad, Mihalcea, 2013-09-29, 1)
However, when fetching it:
assertEquals(
LocalDate.of(
2013, 9, 29
),
userAccount.getSubscribedOn()
);
We get the following failure message:
Expected :2013-09-29
Actual :2013-09-28
This is because in the database the following row was inserted:
| id | first_name | last_name | subscribed_on |
|----|------------|-----------|---------------|
| 1 | Vlad | Mihalcea | 28-09-13 |
Setting the timezone property does not fix the problem:
@Override
protected void additionalProperties(Properties properties) {
properties.setProperty(AvailableSettings.JDBC_TIME_ZONE, "UTC" );
}
because this is not taken into consideration by `LocalDateType`.
( https://hibernate.atlassian.net/browse/HHH-13987#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13987#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100125- sha1:29f7b81 )
4 years, 5 months
[JIRA] (HV-1772) Building multiple ValidatorFactory instances from a single Configuration violates specification for MessageInterpolator
by Steven Walters (JIRA)
Steven Walters ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue
Hibernate Validator ( https://hibernate.atlassian.net/browse/HV?atlOrigin=eyJpIjoiMGY4YzkyMWFlZ... ) / Bug ( https://hibernate.atlassian.net/browse/HV-1772?atlOrigin=eyJpIjoiMGY4Yzky... ) HV-1772 ( https://hibernate.atlassian.net/browse/HV-1772?atlOrigin=eyJpIjoiMGY4Yzky... ) Building multiple ValidatorFactory instances from a single Configuration violates specification for MessageInterpolator ( https://hibernate.atlassian.net/browse/HV-1772?atlOrigin=eyJpIjoiMGY4Yzky... )
Issue Type: Bug Affects Versions: 5.4.3.Final, 6.0.19.Final, 7.0.0.Alpha1, 6.1.4.Final Assignee: Unassigned Attachments: hibernate-validator-configuration-reuse-issue.zip Components: engine Created: 28/Apr/2020 05:33 AM Priority: Major Reporter: Steven Walters ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
The bean validation specification mentions the following
>
>
>
> Clients call Configuration.buildValidatorFactory() to retrieve the
> initialized ValidatorFactory instance. It is legal to invoke
> buildValidatorFactory() several times, e.g. in order to retrieve several
> ValidatorFactory instances with a slightly different configuration (see
> Using Configuration to create several validator factories).
>
>
to indicate that a Configuration can be used to create several ValidatorFactories, but hibernate validation violates this aspect when it comes to MessageInterpolator.
I've attached a small maven project to implicate the issue. One can use
mvn clean verify -Phibernate5
mvn clean verify -Phibernate6
mvn clean verify -Phibernate61
mvn clean verify -Phibernate7
on the attached project to test the different versions (5.4.3.Final, 6.0.19.Final, 6.1.4.Final, and 7.0.0.Alpha1 respectively)
My investigation as to a possible RCA found that this is likely a regression from the change introduced in HV-1131 ( https://hibernate.atlassian.net/browse/HV-1131 ) Closed , at HV-1131 code change ( https://github.com/hibernate/hibernate-validator/commit/c9948dabe5cb309d7... ) , which equates to once getMessageInterpolator() is invoked, the first return is locked-in and all future invocations will always return the same value, even if messageInterpolator() is utilized.
As a workaround to have hibernate respect the bean validation specification, one must reflect on the Configuration and set the messageInterpolator field to null before doing any operation that performs getMessageInterpolator(), such as buildValidatorFactory() (which to honestly state is a rather dirty workaround)
I also cannot state that such a workaround will work long-term (such as with the module system of Java 9+)
( https://hibernate.atlassian.net/browse/HV-1772#add-comment?atlOrigin=eyJp... ) Add Comment ( https://hibernate.atlassian.net/browse/HV-1772#add-comment?atlOrigin=eyJp... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100125- sha1:29f7b81 )
4 years, 5 months
[JIRA] (HSEARCH-3900) drop-and-create strategy is not working at app. startup when "hibernate.search.autoregister_listeners" is set to false. And if true, startup index creation thread are not released, sending the app in out of memory.
by Yoann Rodière (JIRA)
Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HSEARCH-3900 ( https://hibernate.atlassian.net/browse/HSEARCH-3900?atlOrigin=eyJpIjoiY2V... )
Re: drop-and-create strategy is not working at app. startup when "hibernate.search.autoregister_listeners" is set to false. And if true, startup index creation thread are not released, sending the app in out of memory. ( https://hibernate.atlassian.net/browse/HSEARCH-3900?atlOrigin=eyJpIjoiY2V... )
>
>
>
> We have this set correctly.
>
>
Then you probably have something like that somewhere:
hibernate.search.myIndex1.indexmanager = <something that is not "elasticsearch" >
Specifically, I can tell you from your thread dump that "TABLEWC30" is using a Lucene index, not an Elasticsearch one.
>
>
>
> But on startup we are not indexing anything.
>
>
The transport threads are also used to send requests to Elasticsearch to drop/create indexes, or simply to execute search queries. My point is, if they do something, it's because you asked them to.
>
>
>
> > The threads will not stop as long as your application is running. That's
> on purpose.
>
>
>
>
>
> Why is so?
>
>
Because spawning new threads every time we need to do something would be disastrous performance-wise.
>
>
>
> > Was your only problem that "Hibernate Search creates threads"?
>
>
>
>
>
> No, issue is these threads are throwing my application in out of memory
> condition.
>
>
Let's say you have two threads T1 and T2, and 500MB of memory available. Let's say T1 allocates 499MB of memory, then T2 allocates 2MB of memory. The OutOfMemoryError will occur in T2, but obviously T1 is the biggest consumer of memory.
Just because the OutOfMemoryError happpened in these threads, doesn't necessarily mean these threads are the source of your trouble. They could be, but that's far from certain.
>
>
>
> Also If I switch elastic search off in my app, then the application runs
> fine.
>
>
Certainly. If you remove Hibernate Search *and* Elasticsearch from your application, you will need less memory. That doesn't mean that Hibernate Search and Elasticsearch consume too much memory; maybe there is simply not enough memory available.
In your case, the Elasticsearch transport threads are probably just serializing JSON to sent requests to drop/create indexes. Unless you have a very, very complicated schema, I wouldn't expect that to cause too many memory allocations. On the Elasticsearch side, however, the creation of an index can result in significant memory allocations. Maybe Elasticsearch is eating up the memory and your application no longer has enough RAM available?
What is the amount of RAM available on your server, and what are the memory flags ( -Xms / -Xmx on your JVMs (Tomcat *and* Elasticsearch)? What are the processes using the most memory when you encounter your OutOfMemoryError , and how much memory are they using?
Also, if you actually have data that points toward Hibernate Search allocating too much memory (for example Java Flight Recorder recordings), please show me that data, so I can pinpoint which class allocates so much. You can find various tutorials on the web, [this one] ( https://stackoverflow.com/a/54143988/6692043 ) looks like a good starting point.
( https://hibernate.atlassian.net/browse/HSEARCH-3900#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3900#add-comment?atlOrigin... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100125- sha1:29f7b81 )
4 years, 5 months