does Attachments.NEXT_PHASE_DEPS wait for async services or does the next DUP phase start as soon as the service.start returns...
8:52 p.m.
Hi,
In PersistenceUnitServiceHandler [1], we are creating the persistence
unit service (PersistenceUnitServiceImpl [2]) and specifying
Attachments.NEXT_PHASE_DEPS for the service that are creating.
What happens when the service [2] is started asynchronously? Will the
next deployment phase start as soon as the async service is started? Or
will the next deployment phase as soon as the
PersistenceUnitServiceImpl.start method returns? I suspect that it is
as soon as the async start method returns, which means that the JPA
ordering is wrong (with respect to allowing the persistence provider to
rewrite entity classes completely before the POST_MODULE phase starts
for the deployment.)
This came up with an EclipseLink issue [3] with weaving not working in
an EAR that contains war (with JSF managed beans) and a jar that has a
persistence unit/entities. The managed bean classes (indirectly)
reference the entity classes, which causes them to be loaded during the
POST_MODULE phase. We are reaching the POST_MODULE phase sooner than I
expected.
Scott
[1]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[2]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[3] https://community.jboss.org/message/878100#878100
11:15 p.m.
If we don't have anything built in already, we probably could introduce
another service that synchronously waits for the async activity to
completely start and is marked with NEXT_PHASE_DEPS so that the next
deployment phase doesn't start until the background task has completed.
Something else?
Scott
On 06/13/2014 02:52 PM, Scott Marlow wrote:
Hi,
In PersistenceUnitServiceHandler [1], we are creating the persistence
unit service (PersistenceUnitServiceImpl [2]) and specifying
Attachments.NEXT_PHASE_DEPS for the service that are creating.
What happens when the service [2] is started asynchronously? Will the
next deployment phase start as soon as the async service is started? Or
will the next deployment phase as soon as the
PersistenceUnitServiceImpl.start method returns? I suspect that it is
as soon as the async start method returns, which means that the JPA
ordering is wrong (with respect to allowing the persistence provider to
rewrite entity classes completely before the POST_MODULE phase starts
for the deployment.)
This came up with an EclipseLink issue [3] with weaving not working in
an EAR that contains war (with JSF managed beans) and a jar that has a
persistence unit/entities. The managed bean classes (indirectly)
reference the entity classes, which causes them to be loaded during the
POST_MODULE phase. We are reaching the POST_MODULE phase sooner than I
expected.
Scott
[1]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[2]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[3] https://community.jboss.org/message/878100#878100
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:02 a.m.
On 06/13/2014 05:15 PM, Scott Marlow wrote:
If we don't have anything built in already, we probably could
introduce
another service that synchronously waits for the async activity to
completely start and is marked with NEXT_PHASE_DEPS so that the next
deployment phase doesn't start until the background task has completed.
Something else?
If the above idea is just about making the persistence unit service
synchronous, there are probably easier ways to do that (perhaps adding a
sync/async deployment hint for the persistence unit).
Will also need to revisit the single core deadlock case
https://issues.jboss.org/browse/AS7-4786.
Scott
On 06/13/2014 02:52 PM, Scott Marlow wrote:
> Hi,
>
> In PersistenceUnitServiceHandler [1], we are creating the persistence
> unit service (PersistenceUnitServiceImpl [2]) and specifying
> Attachments.NEXT_PHASE_DEPS for the service that are creating.
>
> What happens when the service [2] is started asynchronously? Will the
> next deployment phase start as soon as the async service is started? Or
> will the next deployment phase as soon as the
> PersistenceUnitServiceImpl.start method returns? I suspect that it is
> as soon as the async start method returns, which means that the JPA
> ordering is wrong (with respect to allowing the persistence provider to
> rewrite entity classes completely before the POST_MODULE phase starts
> for the deployment.)
>
> This came up with an EclipseLink issue [3] with weaving not working in
> an EAR that contains war (with JSF managed beans) and a jar that has a
> persistence unit/entities. The managed bean classes (indirectly)
> reference the entity classes, which causes them to be loaded during the
> POST_MODULE phase. We are reaching the POST_MODULE phase sooner than I
> expected.
>
>
> Scott
>
>
> [1]
>
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
>
> [2]
>
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
>
> [3] https://community.jboss.org/message/878100#878100
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:40 p.m.
Scott Marlow wrote:
Hi,
In PersistenceUnitServiceHandler [1], we are creating the persistence
unit service (PersistenceUnitServiceImpl [2]) and specifying
Attachments.NEXT_PHASE_DEPS for the service that are creating.
What happens when the service [2] is started asynchronously? Will the
next deployment phase start as soon as the async service is started? Or
will the next deployment phase as soon as the
PersistenceUnitServiceImpl.start method returns? I suspect that it is
as soon as the async start method returns, which means that the JPA
ordering is wrong (with respect to allowing the persistence provider to
rewrite entity classes completely before the POST_MODULE phase starts
for the deployment.)
It should not matter if it is an async start of not, the phase should
not advance until the service is actually started. This just uses normal
MSC service deps, and given that we use async start a fair bit it would
surprise me if it was at fault here.
Stuart
This came up with an EclipseLink issue [3] with weaving not working in
an EAR that contains war (with JSF managed beans) and a jar that has a
persistence unit/entities. The managed bean classes (indirectly)
reference the entity classes, which causes them to be loaded during the
POST_MODULE phase. We are reaching the POST_MODULE phase sooner than I
expected.
Scott
[1]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[2]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
[3] https://community.jboss.org/message/878100#878100
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:44 p.m.
It should not matter if it is an async start of not, the phase should
not advance until the service is actually started. This just uses normal
MSC service deps, and given that we use async start a fair bit it would
surprise me if it was at fault here.
Stuart
Thanks Stuart. Is there a way to get EAR subdeployments to run in the
same phase? Seems like the .war subdeployment is reaching the
POST_MODULE PHASE before the .jar subdeployment does.
I looked at updated TRACE logging output on the forum thread [1]. This
is for an ear deployment, that contains an EJB jar 'tcApp.jar' with
entity classes and a WEB jar that contains managed beans that the
JSFManagedBeanProcessor will load. The managed bean classes reference
the entity classes.
[2] shows that we are first starting the persistence unit (via
PersistenceProvider.createContainerEntityManagerFactory) for the
tcApp.jar subdeployment. However, the tcWeb.war subdeployment gets to a
later phase (POST_MODULE) [3] before the PersistenceUnitServiceImpl has
called StartContext.complete(). In the POST_MODULE [3]
JSFManagedBeanProcessor loads the referenced managed beans, which loads
the entity classes (see [4] which shows one of the entities being loaded).
By the time that PersistenceUnitServiceImpl has called
StartContext.complete() [5], several entity classes are already loaded.
Scott
[1] https://community.jboss.org/thread/241821
[2] 2014-06-19 14:13:54,873 TRACE [org.jboss.as.jpa] (ServerService
Thread Pool -- 57) calling createContainerEntityManagerFactory for
pu=EnterpriseApplication1.ear/tcApp.jar#MyPU with integration
properties={eclipselink.archive.factory=org.jipijapa.eclipselink.JBossArchiveFactoryImpl,
eclipselink.target-server=org.jipijapa.eclipselink.JBossAS7ServerPlatform,
eclipselink.logging.logger=org.jipijapa.eclipselink.JBossLogger},
application properties={eclipselink.jpa.uppercase-column-names=true,
eclipselink.cache.size.default=5000, eclipselink.logging.level=FINE,
eclipselink.logging.logger=JavaLogger}
[3] 2014-06-19 14:13:55,408 INFO [org.jboss.as.jsf] (MSC service thread
1-10) !!!JSFManagedBeanProcessor deployment phase=POST_MODULE,
managedBean=tc.web.controller.settings.OrganizationConfigController,
module classloader=ModuleClassLoader for Module
"deployment.EnterpriseApplication1.ear.tcWeb.war:main" from Service
Module Loader
[4] 2014-06-19 14:13:55,434 TRACE [org.jboss.as.jpa] (MSC service thread
1-10) !!!JPADelegatingClassFileTransformer.transform
tc/entities/type/Attribute
[5] 2014-06-19 14:13:58,014 TRACE [org.jboss.as.jpa] (ServerService
Thread Pool -- 57) !!!PersistenceUnitServiceImpl startcontext marked
complete
3:25 p.m.
>
Thanks Stuart. Is there a way to get EAR subdeployments to run in the
same phase? Seems like the .war subdeployment is reaching the
POST_MODULE PHASE before the .jar subdeployment does.
So they do actually run in the same phase, kinda. With an ear first the
top level deployment runs a phase, and then all sub deployments run the
same phase in parallel.
I think the problem here is that NEXT_PHASE_DEPS only applies to the
current deployment. So all the modules will run FIRST_MODULE_USE, but
only the jar will actually wait for the PU to be installed before
running post module, the top level and war deployments will run
POST_MODULE to completion (but nothing more will happen until the jar
deployment has also run POST_MODULE).
I think you need to make sure that every deployment/subdeployment ends
up with the NEXT_PHASE_DEP set up.
Stuart
I looked at updated TRACE logging output on the forum thread [1]. This
is for an ear deployment, that contains an EJB jar 'tcApp.jar' with
entity classes and a WEB jar that contains managed beans that the
JSFManagedBeanProcessor will load. The managed bean classes reference
the entity classes.
[2] shows that we are first starting the persistence unit (via
PersistenceProvider.createContainerEntityManagerFactory) for the
tcApp.jar subdeployment. However, the tcWeb.war subdeployment gets to a
later phase (POST_MODULE) [3] before the PersistenceUnitServiceImpl has
called StartContext.complete(). In the POST_MODULE [3]
JSFManagedBeanProcessor loads the referenced managed beans, which loads
the entity classes (see [4] which shows one of the entities being loaded).
By the time that PersistenceUnitServiceImpl has called
StartContext.complete() [5], several entity classes are already loaded.
Scott
[1] https://community.jboss.org/thread/241821
[2] 2014-06-19 14:13:54,873 TRACE [org.jboss.as.jpa] (ServerService
Thread Pool -- 57) calling createContainerEntityManagerFactory for
pu=EnterpriseApplication1.ear/tcApp.jar#MyPU with integration
properties={eclipselink.archive.factory=org.jipijapa.eclipselink.JBossArchiveFactoryImpl,
eclipselink.target-server=org.jipijapa.eclipselink.JBossAS7ServerPlatform,
eclipselink.logging.logger=org.jipijapa.eclipselink.JBossLogger},
application properties={eclipselink.jpa.uppercase-column-names=true,
eclipselink.cache.size.default=5000, eclipselink.logging.level=FINE,
eclipselink.logging.logger=JavaLogger}
[3] 2014-06-19 14:13:55,408 INFO [org.jboss.as.jsf] (MSC service thread
1-10) !!!JSFManagedBeanProcessor deployment phase=POST_MODULE,
managedBean=tc.web.controller.settings.OrganizationConfigController,
module classloader=ModuleClassLoader for Module
"deployment.EnterpriseApplication1.ear.tcWeb.war:main" from Service
Module Loader
[4] 2014-06-19 14:13:55,434 TRACE [org.jboss.as.jpa] (MSC service thread
1-10) !!!JPADelegatingClassFileTransformer.transform
tc/entities/type/Attribute
[5] 2014-06-19 14:13:58,014 TRACE [org.jboss.as.jpa] (ServerService
Thread Pool -- 57) !!!PersistenceUnitServiceImpl startcontext marked
complete
3:52 p.m.
On 06/20/2014 09:25 AM, Stuart Douglas wrote:
>>
>
> Thanks Stuart. Is there a way to get EAR subdeployments to run in the
> same phase? Seems like the .war subdeployment is reaching the
> POST_MODULE PHASE before the .jar subdeployment does.
So they do actually run in the same phase, kinda. With an ear first the
top level deployment runs a phase, and then all sub deployments run the
same phase in parallel.
I think the problem here is that NEXT_PHASE_DEPS only applies to the
current deployment. So all the modules will run FIRST_MODULE_USE, but
only the jar will actually wait for the PU to be installed before
running post module, the top level and war deployments will run
POST_MODULE to completion (but nothing more will happen until the jar
deployment has also run POST_MODULE).
I think you need to make sure that every deployment/subdeployment ends
up with the NEXT_PHASE_DEP set up.
Ah, excellent solution! Thanks Stuart!
Stuart
4:05 p.m.
On 06/20/2014 09:52 AM, Scott Marlow wrote:
On 06/20/2014 09:25 AM, Stuart Douglas wrote:
>
>>>
>>
>> Thanks Stuart. Is there a way to get EAR subdeployments to run in the
>> same phase? Seems like the .war subdeployment is reaching the
>> POST_MODULE PHASE before the .jar subdeployment does.
>
> So they do actually run in the same phase, kinda. With an ear first the
> top level deployment runs a phase, and then all sub deployments run the
> same phase in parallel.
>
> I think the problem here is that NEXT_PHASE_DEPS only applies to the
> current deployment. So all the modules will run FIRST_MODULE_USE, but
> only the jar will actually wait for the PU to be installed before
> running post module, the top level and war deployments will run
> POST_MODULE to completion (but nothing more will happen until the jar
> deployment has also run POST_MODULE).
>
> I think you need to make sure that every deployment/subdeployment ends
> up with the NEXT_PHASE_DEP set up.
Ah, excellent solution! Thanks Stuart!
I created WFLY-3531 for this.
>
> Stuart
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3606
days inactive
3613
days old
7 comments
2 participants
participants (2)
-
Scott Marlow -
Stuart Douglas