[JBoss JIRA] (WFLY-9054) Use of schedule expression start/end date for (Database) persistent calendar timers fail if the server is restarted and the timer reloaded
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-9054?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-9054:
----------------------------------------
First Analysis
The fields SCHEDULE_EXPR_START_DATE SCHEDULE_EXPR_END_DATE are VARCHAR2 (or VARCHAR for others)
The internal value is java.util.Date which is converted to java.sql.Timestamp
Other database write the String as "YYYY-MM-DD hh:mm:ss.fffffffff' but Oracle do it in a different format like '06-JUL-17 01.54.00.269000000 PM', but expect to read the correct one.
Changing the value into the correct format after creation work correct.
Also changing the field type to TIMESTAMP work correct.
It seems an Oracle specific issue
> Use of schedule expression start/end date for (Database) persistent calendar timers fail if the server is restarted and the timer reloaded
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9054
> URL: https://issues.jboss.org/browse/WFLY-9054
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Alpha1
> Environment: Oracle Database as datasource for timers
> <timer-service thread-pool-name="default" default-data-store="default-store">
> <data-stores>
> <database-data-store name="default-store" datasource-jndi-name="jboss/datasources/OracleDatasource"/>
> </data-stores>
> </timer-service>
> Reporter: Wolf-Dieter Fink
> Labels: ejb, timers, timerservice
>
> If Calendar timers are created programatically it is possible to use the javax.ejb.ScheduleExpression and set start() end() as a Date.
> If the timer is persistent and the database is Oracle (here 12c ojdbc7 driver) a server restart will show the following Exception is:
> 13:55:00,450 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 63) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=bd2e59a0-bdf6-43a1-9241-fd3a0b3a72da) from its persistent state: java.sql.SQLException: Invalid conversion requested
> at oracle.jdbc.driver.CharCommonAccessor.getTimestamp(CharCommonAccessor.java:420)
> at oracle.jdbc.driver.T4CVarcharAccessor.getTimestamp(T4CVarcharAccessor.java:644)
> at oracle.jdbc.driver.GeneratedStatement.getTimestamp(GeneratedStatement.java:360)
> at oracle.jdbc.driver.GeneratedScrollableResultSet.getTimestamp(GeneratedScrollableResultSet.java:1008)
> at org.jboss.jca.adapters.jdbc.WrappedResultSet.getTimestamp(WrappedResultSet.java:2140)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.timerFromResult(DatabaseTimerPersistence.java:535)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.loadActiveTimers(DatabaseTimerPersistence.java:452)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:953)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:693)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:225)
> at org.jboss.as.ejb3.component.EJBComponent.start(EJBComponent.java:588)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:133)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff]
> at java.sql.Timestamp.valueOf(Timestamp.java:237)
> at oracle.jdbc.driver.CharCommonAccessor.getTimestamp(CharCommonAccessor.java:415)
> ... 18 more
> As a result the timer seems created with a new id and the entry within the timer-table is duplicated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9054) Use of schedule expression start/end date for (Database) persistent calendar timers fail if the server is restarted and the timer reloaded
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-9054:
--------------------------------------
Summary: Use of schedule expression start/end date for (Database) persistent calendar timers fail if the server is restarted and the timer reloaded
Key: WFLY-9054
URL: https://issues.jboss.org/browse/WFLY-9054
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Alpha1
Environment: Oracle Database as datasource for timers
<timer-service thread-pool-name="default" default-data-store="default-store">
<data-stores>
<database-data-store name="default-store" datasource-jndi-name="jboss/datasources/OracleDatasource"/>
</data-stores>
</timer-service>
Reporter: Wolf-Dieter Fink
If Calendar timers are created programatically it is possible to use the javax.ejb.ScheduleExpression and set start() end() as a Date.
If the timer is persistent and the database is Oracle (here 12c ojdbc7 driver) a server restart will show the following Exception is:
13:55:00,450 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 63) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=bd2e59a0-bdf6-43a1-9241-fd3a0b3a72da) from its persistent state: java.sql.SQLException: Invalid conversion requested
at oracle.jdbc.driver.CharCommonAccessor.getTimestamp(CharCommonAccessor.java:420)
at oracle.jdbc.driver.T4CVarcharAccessor.getTimestamp(T4CVarcharAccessor.java:644)
at oracle.jdbc.driver.GeneratedStatement.getTimestamp(GeneratedStatement.java:360)
at oracle.jdbc.driver.GeneratedScrollableResultSet.getTimestamp(GeneratedScrollableResultSet.java:1008)
at org.jboss.jca.adapters.jdbc.WrappedResultSet.getTimestamp(WrappedResultSet.java:2140)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.timerFromResult(DatabaseTimerPersistence.java:535)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.loadActiveTimers(DatabaseTimerPersistence.java:452)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:953)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:693)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:225)
at org.jboss.as.ejb3.component.EJBComponent.start(EJBComponent.java:588)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:133)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff]
at java.sql.Timestamp.valueOf(Timestamp.java:237)
at oracle.jdbc.driver.CharCommonAccessor.getTimestamp(CharCommonAccessor.java:415)
... 18 more
As a result the timer seems created with a new id and the entry within the timer-table is duplicated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2202) FD_ALL: sanity check that interval is less than timeout
by Bela Ban (JIRA)
Bela Ban created JGRP-2202:
------------------------------
Summary: FD_ALL: sanity check that interval is less than timeout
Key: JGRP-2202
URL: https://issues.jboss.org/browse/JGRP-2202
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 4.0.5
If {{timeout}} is 5000, but {{interval}} is 8000 (and {{timeout_check_interval}} 2000), then we'll always get (false) suspicions. These don't actually exclude a member in most cases, but lead to annoying suspicion warnings.
Log a warn message if such a config is found on startup.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Giovanni Lovato (JIRA)
Giovanni Lovato created WFLY-9053:
-------------------------------------
Summary: AbstractMethodError with Hibernate 5.2
Key: WFLY-9053
URL: https://issues.jboss.org/browse/WFLY-9053
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 11.0.0.Alpha1
Reporter: Giovanni Lovato
Assignee: Scott Marlow
I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
{code:xml}
<property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
{code}
Hibernate 5.2 modules are placed in the {{modules}} directory.
This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
... 5 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9046) org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9046?page=com.atlassian.jira.plugin.... ]
Chao Wang updated WFLY-9046:
----------------------------
Component/s: (was: Security Manager)
> org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
> -------------------------------------------------------------------------------
>
> Key: WFLY-9046
> URL: https://issues.jboss.org/browse/WFLY-9046
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Chao Wang
>
> org.jboss.as.test.integration.ee.concurrent.Default* tests fail with security manager. There are missing permissions "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")":
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.wildfly.security.auth.server.SecurityDomain.getCurrent(SecurityDomain.java:155)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9046) org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9046?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9046:
-------------------------------
Assignee: Chao Wang (was: Tomaz Cerar)
> org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
> -------------------------------------------------------------------------------
>
> Key: WFLY-9046
> URL: https://issues.jboss.org/browse/WFLY-9046
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Chao Wang
>
> org.jboss.as.test.integration.ee.concurrent.Default* tests fail with security manager. There are missing permissions "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")":
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.wildfly.security.auth.server.SecurityDomain.getCurrent(SecurityDomain.java:155)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months