[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=eyJpIjoiZjA... )
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=eyJpIjoiZjA... )
Ok, I think I'm not getting my message through.
So, let's get back to the basics.
First, autoregister_listeners=false disables Hibernate search completely. If you set that, nothing will work. It's normal. It's always been that way. Any problem you have with this setting is completely irrelevant. Please forget about this setting.
Second, your problem is about performance on bootstrap. Please give more information about that: the name of the threads causing that trouble, as well as thread dumps and/or stacktraces.
( 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:c966059 )
4 years, 4 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 Ronak S (JIRA)
Ronak S ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ea56c8... ) *commented* on HSEARCH-3900 ( https://hibernate.atlassian.net/browse/HSEARCH-3900?atlOrigin=eyJpIjoiMmY... )
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=eyJpIjoiMmY... )
Yoann, thanks for the response.
I’ve few queries with reference to your answer. Below are the same:
>
>
>
> Regardless... I'd stay away from this setting. It probably doesn't do what
> you think it does.
>
>
We have been using Hibernate Search from last 1.5 years on below version and these are newer than 5.5.
We still never faced this issue, we even did not manually provided the configuration of autoregister_listeners in our hibernate.cfg file. Still it was all well, the problem only started after upgrading to 5.11.5.
>
>
>
> If you want to enable Hibernate Search, but prevent automatic indexing,
> see here (
> https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/...
> ) instead. You just have to set this:
>
>
>
> hibernate.search.indexing_strategy = manual
>
>
>
> Hibernate Search will still start up, but entity persisting events will be
> ignored. You will have to use the mass indexer in order to index your
> data, or explicit index commands. See here (
> https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/...
> ) for more information.
>
>
I can not set it to manual, as in our application we have used hibernate search to update the elastic database as an when we have an add/update/delete on the entities which are @Indexed annotated. For eg. If a user adds a client data, this needs to be added on elastic server, as the search part is provided through elastic server.
>
>
>
> I'll need to know which setting you're talking about. Both autoregister_listeners
> and indexing_strategy were introduced before version 5.6 , so long before
> Elasticsearch support was event introduced.
>
>
I’m talking about autoregister_listeners and indexing_strategy settings. As now if I keep the autoregister_listeners to false then my drop-and-create strategy does not work any longer. As we require this to update the schema on elastic side, once we modify any entity to include/exclude fields from elastic schema. These were even working correctly under 5.9 version.
>
>
>
> My concern is, we do have an option of create-and-drop of indexes at sever
> startup, are we going to remove this option?
>
>
>
> Which you replied with “No“
>
>
If we are not planning to remove this and it will be available. How do you suggest of doing this with current scenario. Where if autoregister_listeners are true than we have the performance issue and when it is false, the whole hibernate search is disabled in the application?
>
>
>
> No. It just removes all documents, but it preserves the same schema.
>
>
>
> The option to drop and recreate indexes in the mass indexer was introduced
> in Search 6.0.0.Beta6 ( HSEARCH-3751 (
> https://hibernate.atlassian.net/browse/HSEARCH-3751 ) ); see the dropAndCreateSchemaOnStart
> parameter here (
> https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#...
> ).
>
>
See, we can only update the data with startAndWait, but how will I refresh my schema with this as that is only possible with drop-and-create, ryt?
Further, we were planning to go to the latest version, but then it’s in BETA stage. So we can not adapt a BETA version for our product. Do you suggest to move to the version 6 BETA, will doing this resolve all these issues?
>
>
>
> No, that's useful to trigger mass indexing, reindex your data while taking
> your application offline. After that, you can restart your application and
> re-enable automatic indexing.
>
>
>
> Some people also don't use automatic indexing at all and just reindex
> their whole database periodically. That's not for everyone, though.
>
>
MassIndexing is fine and we do it the way you are suggesting with startAndWait(), but how do I achieve the refresh of schema. Also as you said its not the case with everyone, and yes we can not do periodic refresh, instead we need it at runtime. As I explained above in one of the comments.
>
>
>
> As I already explained, setting hibernate.search.autoregister_listeners to
> false will just *disable Hibernate Search*. So yes, that's expected.
>
>
Are you suggesting that now the automatic indexing on add/update/delete support is lost from 5.11. Because honestly it was all fine in 5.9.
>
>
>
> Where do the problems seem to happen? Just when booting? Or when the
> application handles HTTP requests that result in write operations on the
> database?
>
>
It’s only at the server booting/startup time. Otherwise the application is working as expected.
>
>
>
> Did you change anything at all?
>
>
>
> Changes in your model and Search mapping could lead to dramatic
> performance problems if they trigger a lot of reindexing ( @ContainedIn ).
> I'm talking about indexing one entity leading to loading half the database.
> You need to be very careful about what you do with @ContainedIn.
>
>
>
> Switching from Lucene to Elasticsearch can also represent a high cost if
> your application is very write-intensive. In particular, you should not
> enable hibernate.search.default.elasticsearch.refresh_after_write. This
> setting will lead to terrible performance in write-intensive applications.
>
>
>
No I did not make any change with respect to @ContainedIn we had this functionality in 5.9 too. And yes we do have @ContainedIn relationships in elastic.
Further, we were already on lucene and did not migrate to Elasticsearch. Also I’ve not provided hibernate.search.default.elasticsearch.refresh_after_write in my hibernate config.
At last,
>
>
>
> As I explained above, with autoregister_listeners set to false , Hibernate
> Search is disabled. So of course all Hibernate Search features are
> disabled as well.
>
>
If this setting is off, I’m left with just the hibernate search jars in my application, doing nothing 🙂.
Please help me to overcome this issue, as now I’m more curious to understand why it was fine in 5.9 and not now with 5.11?
Just look at this scenario in a way that my application is now dead from hibernate search side.
Please revert if you need more details on configuration, jar dependencies we have or any other info you require to understand it in more better way.
( 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:c966059 )
4 years, 4 months
[JIRA] (HHH-13982) Incorrect FK column generated/used when using @OneToMany with @Inheritance(strategy = InheritanceType.JOINED)
by Василий Музыченко (JIRA)
Василий Музыченко ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5a72fc7... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNjcyMTMwODZj... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiNjcyMT... ) HHH-13982 ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiNjcyMT... ) Incorrect FK column generated/used when using @OneToMany with @Inheritance(strategy = InheritanceType.JOINED) ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiNjcyMT... )
Change By: Василий Музыченко ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5a72fc7... )
[^hibernate-one-to-many-bug.zip]
Hi everyone. Here are some entities to demonstrate this (getters/setters omitted for brevity):
Parent entity (container):
{code:java}
@Entity
public class Parent {
@Id
@GeneratedValue(generator = "uuid")
@GenericGenerator(name = "uuid", strategy = "uuid2")
private String uuid;
@OneToMany(mappedBy = "parent")
private Set<FirstChild> firstChildren;
}
{code}
Child (element) base class:
{code:java}
@Entity
@DiscriminatorColumn(name = "discriminator")
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class ChildBase {
public static final String DISCRIMINATOR_FIRST = "FIRST";
@Id
@GeneratedValue(generator = "uuid")
@GenericGenerator(name = "uuid", strategy = "uuid2")
private String uuid;
@ManyToOne
private Parent parent;
}
{code}
And element itself:
{code:java}
@Entity
@DiscriminatorValue(ChildBase.DISCRIMINATOR_FIRST)
public class FirstChild extends ChildBase {
private String firstChildField;
}
{code}
This results in the folowing statements being generated:
{code:java}
create table ChildBase (
discriminator varchar(31) not null,
uuid varchar(255) not null,
parent_uuid varchar(255),
primary key (uuid)
)
create table FirstChild (
firstChildField varchar(255),
uuid varchar(255) not null,
parent_uuid varchar(255),
primary key (uuid)
)
{code}
Note that ` * parent_uuid ` * column is present in both ` * ChildBase ` * and ` * FirstChild ` *. Which to my understanding is incorrect, since ` * FirstChild ` * should only contain columns, defined in ` * FirstChild ` * itself. Also, removing ` * @OneToMany ` * makes this additional column disappear.
Furthermore Hibernate will actually use correct column when persisting data, but incorrect one when loading. Thus failing to find any rows. This behaviour can be seen it tests that provided.
As a workaround you can use ` * targetEntity = ChildBase.class ` * on ` * @OneToMany ` * but this results in ugly things and suboptimal SQL when working with this collection, so it is far from ideal.
( https://hibernate.atlassian.net/browse/HHH-13982#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13982#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:c966059 )
4 years, 4 months
[JIRA] (HHH-13982) Incorrect FK column generated/used when using @OneToMany with @Inheritance(strategy = InheritanceType.JOINED)
by Василий Музыченко (JIRA)
Василий Музыченко ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5a72fc7... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiZWVhZTU4MjVk... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiZWVhZT... ) HHH-13982 ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiZWVhZT... ) Incorrect FK column generated/used when using @OneToMany with @Inheritance(strategy = InheritanceType.JOINED) ( https://hibernate.atlassian.net/browse/HHH-13982?atlOrigin=eyJpIjoiZWVhZT... )
Issue Type: Bug Affects Versions: 5.2.18, 5.3.16, 5.4.14 Assignee: Unassigned Attachments: hibernate-one-to-many-bug.zip Components: hibernate-core Created: 27/Apr/2020 00:27 AM Priority: Major Reporter: Василий Музыченко ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5a72fc7... )
hibernate-one-to-many-bug.zip ( https://hibernate.atlassian.net/secure/attachment/49656/49656_hibernate-o... ) Hi everyone. Here are some entities to demonstrate this (getters/setters omitted for brevity):
Parent entity (container):
@Entity
public class Parent {
@Id
@GeneratedValue(generator = "uuid" )
@GenericGenerator(name = "uuid" , strategy = "uuid2" )
private String uuid;
@OneToMany(mappedBy = "parent" )
private Set<FirstChild> firstChildren;
}
Child (element) base class:
@Entity
@DiscriminatorColumn(name = "discriminator" )
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class ChildBase {
public static final String DISCRIMINATOR_FIRST = "FIRST" ;
@Id
@GeneratedValue(generator = "uuid" )
@GenericGenerator(name = "uuid" , strategy = "uuid2" )
private String uuid;
@ManyToOne
private Parent parent;
}
And element itself:
@Entity
@DiscriminatorValue(ChildBase.DISCRIMINATOR_FIRST)
public class FirstChild extends ChildBase {
private String firstChildField;
}
This results in the folowing statements being generated:
create table ChildBase (
discriminator varchar(31) not null ,
uuid varchar(255) not null ,
parent_uuid varchar(255),
primary key (uuid)
)
create table FirstChild (
firstChildField varchar(255),
uuid varchar(255) not null ,
parent_uuid varchar(255),
primary key (uuid)
)
Note that `parent_uuid` column is present in both `ChildBase` and `FirstChild`. Which to my understanding is incorrect, since `FirstChild` should only contain columns, defined in `FirstChild` itself. Also, removing `@OneToMany` makes this additional column disappear.
Furthermore Hibernate will actually use correct column when persisting data, but incorrect one when loading. Thus failing to find any rows. This behaviour can be seen it tests that provided.
As a workaround you can use `targetEntity = ChildBase.class` on `@OneToMany` but this results in ugly things and suboptimal SQL when working with this collection, so it is far from ideal.
( https://hibernate.atlassian.net/browse/HHH-13982#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13982#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:c966059 )
4 years, 4 months