[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6554:
------------------------------------
Also, your hibernate cache-container should use module="org.hibernate.infinispan".
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6554:
------------------------------------
You cannot use org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory, as it requires dependencies established by the DeploymentUnitProcessors from the JPA subsystem. These don't get run if the JPA subsystem isn't processing your persistence.xml.
org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory *should* work. Can you paste any exceptions?
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6576) mod_cluster advertise="false" does not disable advertise if there are no proxies configured
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6576?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6576:
---------------------------------
Description:
{noformat}
17:05:56,822 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.2.Final
17:05:56,833 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
{noformat}
{noformat}
[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration:read-resource
{
"outcome" => "success",
"result" => {
"advertise" => false,
"advertise-security-key" => undefined,
"advertise-socket" => undefined,
{noformat}
> mod_cluster advertise="false" does not disable advertise if there are no proxies configured
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6576
> URL: https://issues.jboss.org/browse/WFLY-6576
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> {noformat}
> 17:05:56,822 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.2.Final
> 17:05:56,833 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> {noformat}
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration:read-resource
> {
> "outcome" => "success",
> "result" => {
> "advertise" => false,
> "advertise-security-key" => undefined,
> "advertise-socket" => undefined,
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Kevin Chen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Kevin Chen commented on WFLY-6561:
----------------------------------
We're not manually creating timers. We're using the JavaEE API with TimerService and @Timeout annotations. I can do the last 2 lines during our EJB startup and timed method execution.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1517:
-------------------------------------
Labels: 2.2 (was: )
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: 2.2
> Fix For: 3.0.0.Alpha1
>
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1517:
----------------------------------------
Fix Version/s: 3.0.0.Alpha1
Assignee: Ladislav Thon (was: Brian Stansberry)
Resolution: Done
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Ladislav Thon
> Priority: Blocker
> Labels: 2.2
> Fix For: 3.0.0.Alpha1
>
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Kevin Chen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Kevin Chen commented on WFLY-6561:
----------------------------------
Will add when to a timer method when the class blows up. The one that blew up in particular was considered obsolete and we could delete it but there are other timed classes that are still relevant so would have to add the above lines to all of them.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months