[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1066:
----------------------------------------
LOL. Yes, it's been a loooong while!
I'm clueless myself but got my info from a source who shall remain nameless. Something about how MERGE "uses the Event.FIND_MBRS_EVT, same as MERGE2".
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Tristan Tarrant
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on WFLY-1066:
--------------------------------
Hi [~brian.stansberry] Brian,
you've been away from JGroups for a while haven't you? :-)
MERGE3 - contrary to MERGE2 - doesn't use discovery anymore!
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Tristan Tarrant
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1066:
----------------------------------------
Thanks, Dominik.
We'll need something where servers publish data only when it changes and then they can perform some sort of very simple query to read. Having servers do a complex set of queries to analyze the domain won't scale. For example, JGroups discovery runs periodically, both when a channel connects and when merge protocols like MERGE3 run. So in a large cluster we can't have possibly hundreds of nodes performing multiple ops reading data.
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Tristan Tarrant
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range header do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Summary: Range header do not seem to be handled correctly and prevents video delivery in Chrome and Safari (was: Range header do not seem to be handled correctly and prevents video delivery in Chrome)
> Range header do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Summary: Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari (was: Range header do not seem to be handled correctly and prevents video delivery in Chrome and Safari)
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Description:
Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
After enabling range headers as described here:
https://developer.jboss.org/message/953058#953058
I made some range requests via `curl` to see what is being returned:
This is the result of a request to *WildFly* with the Range headers enabled:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
X-Powered-By: Undertow/1
Server: WildFly/10
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 16:59:55 GMT
{noformat}
This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
{noformat}
$ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"8200890-1458232627000"
Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
Content-Range: bytes 0-8200889/8200890
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 17:00:08 GMT
{noformat}
I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
was:
Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
After enabling range headers as described here:
https://developer.jboss.org/message/953058#953058
I made some range requests via `curl` to see what is being returned:
This is the result of a request to *WildFly* with the Range headers enabled:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
X-Powered-By: Undertow/1
Server: WildFly/10
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 16:59:55 GMT
{noformat}
This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat8*:
{noformat}
$ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"8200890-1458232627000"
Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
Content-Range: bytes 0-8200889/8200890
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 17:00:08 GMT
{noformat}
I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range header do not seem to be handled correctly and prevents video delivery in Chrome
by Jason Holmberg (JIRA)
Jason Holmberg created WFLY-6413:
------------------------------------
Summary: Range header do not seem to be handled correctly and prevents video delivery in Chrome
Key: WFLY-6413
URL: https://issues.jboss.org/browse/WFLY-6413
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: WildFly 10.0.0.Final
Windows 7 or Mac 10.11.3
Java 8
Chrome, Firefox, Safari
Reporter: Jason Holmberg
Assignee: Stuart Douglas
Priority: Critical
Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
After enabling range headers as described here:
https://developer.jboss.org/message/953058#953058
I made some range requests via `curl` to see what is being returned:
This is the result of a request to *WildFly* with the Range headers enabled:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
X-Powered-By: Undertow/1
Server: WildFly/10
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 16:59:55 GMT
{noformat}
This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat8*:
{noformat}
$ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"8200890-1458232627000"
Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
Content-Range: bytes 0-8200889/8200890
Content-Type: video/mp4
Content-Length: 8200890
Date: Fri, 18 Mar 2016 17:00:08 GMT
{noformat}
I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6412) Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
by Gábor Péntek (JIRA)
[ https://issues.jboss.org/browse/WFLY-6412?page=com.atlassian.jira.plugin.... ]
Gábor Péntek updated WFLY-6412:
-------------------------------
Steps to Reproduce:
Set timer persistence to db in domain.xml:
{code:java}
<timer-service thread-pool-name="default" default-data-store="default-db-store">
<data-stores>
<database-data-store name="default-db-store" datasource-jndi-name="java:jboss/datasources/timerDS" database="oracle" partition="default"/>
</data-stores>
</timer-service>
{code}
Create a simple timer:
{code:java}
@Schedule(hour="*", minute="*", second="*/10")
public void testTimer() {
logger.warn("Test timer executed at {}", System.currentTimeMillis());
}
{code}
*Either:*
Start the application on a cluster with more than one running node.
*or*
Start only one node of the cluster.
Start the application. You should see the timer running in the logs.
Open a session to the database from a db client (i.e. sqlplus)
Between two timer executions, set the connection to serializable and update the timer's row in the database:
{code:java}
SET transaction ISOLATION level serializable;
UPDATE JBOSS_EJB_TIMER
SET NEXT_DATE ='16-MÁRC. -18 23.30.00,000000000',
PREVIOUS_RUN ='16-MÁRC. -18 23.30.00,000000000' ,
TIMER_STATE ='ACTIVE'
WHERE TIMED_OBJECT_ID='app-1.0.0-SNAPSHOT.app-1.0.0-SNAPSHOT.TimerService'
AND ID ='db266f25-883a-44ec-845f-4e45fe727a3a'
AND PARTITION_NAME ='default';
{code}
Until the transaction is commited, the server does not log any more execution since the server's connection is blocked until commit.
After the transaction in sqlplus is commited the server throws a jdbcException with root cause
ORA-08177: can't serialize access for this transaction
*Test results:*
{noformat}
[Server:server-one] 16:05:10,008 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 2) Test timer executed at 1458572710008
[Server:server-one] 16:05:20,009 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 7) Test timer executed at 1458572720009
[Server:server-one] 16:05:30,008 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 4) Test timer executed at 1458572730008
[Server:server-one] 16:05:42,792 ERROR [org.jboss.as.ejb3] (EJB default - 8) WFLYEJB0164: Exception running timer task for timer [id=db266f25-883a-44ec-845f-4e45fe727a3a timedObjectId=jelenteskezelo-1.0.0-SNAPSHOT.jelenteskezelo-1.0.0-SNAPSHOT.UtemezoService auto-timer?:true persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5ae465ae initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Mar 21 16:05:40 CET 2016 timerState=ACTIVE info=null] on EJB jelenteskezelo-1.0.0-SNAPSHOT.jelenteskezelo-1.0.0-SNAPSHOT.UtemezoService: java.lang.RuntimeException: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
[Server:server-one]
[Server:server-one] at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:421)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
[Server:server-one] at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Server:server-one] Caused by: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
[Server:server-one]
[Server:server-one] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:447)
[Server:server-one] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
[Server:server-one] at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:951)
[Server:server-one] at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:513)
[Server:server-one] at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:227)
[Server:server-one] at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
[Server:server-one] at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:208)
[Server:server-one] at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1046)
[Server:server-one] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1336)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3613)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3694)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1354)
[Server:server-one] at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
[Server:server-one] at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:410)
[Server:server-one] ... 8 more
[Server:server-one]
{noformat}
was:
Set timer persistence to db in domain.xml:
{code:java}
<timer-service thread-pool-name="default" default-data-store="default-db-store">
<data-stores>
<database-data-store name="default-db-store" datasource-jndi-name="java:jboss/datasources/timerDS" database="oracle" partition="default"/>
</data-stores>
</timer-service>
{code}
Create a simple timer:
{code:java}
@Schedule(hour="*", minute="*", second="*/10")
public void testTimer() {
logger.warn("Test timer executed at {}", System.currentTimeMillis());
}
{code}
*Either:*
Start the application on a cluster with more than one running node.
*or*
Start only one node of the cluster.
Start the application. You should see the timer running in the logs.
Open a session to the database from a db client (i.e. sqlplus)
Between two timer executions, set the connection to serializable and update the timer's row in the database:
{code:java}
SET transaction ISOLATION level serializable;
UPDATE JBOSS_EJB_TIMER
SET NEXT_DATE ='16-MÁRC. -18 23.30.00,000000000',
PREVIOUS_RUN ='16-MÁRC. -18 23.30.00,000000000' ,
TIMER_STATE ='ACTIVE'
WHERE TIMED_OBJECT_ID='app-1.0.0-SNAPSHOT.app-1.0.0-SNAPSHOT.TimerService'
AND ID ='db266f25-883a-44ec-845f-4e45fe727a3a'
AND PARTITION_NAME ='default';
{code}
Until the transaction is commited, the server does log any more execution since the server's connection is blocked until commit.
After the transaction in sqlplus is commited the server throws a jdbcException with root cause
ORA-08177: can't serialize access for this transaction
*Test results:*
{noformat}
[Server:server-one] 16:05:10,008 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 2) Test timer executed at 1458572710008
[Server:server-one] 16:05:20,009 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 7) Test timer executed at 1458572720009
[Server:server-one] 16:05:30,008 WARN [hu.eeszt.batch.UtemezoService] (EJB default - 4) Test timer executed at 1458572730008
[Server:server-one] 16:05:42,792 ERROR [org.jboss.as.ejb3] (EJB default - 8) WFLYEJB0164: Exception running timer task for timer [id=db266f25-883a-44ec-845f-4e45fe727a3a timedObjectId=jelenteskezelo-1.0.0-SNAPSHOT.jelenteskezelo-1.0.0-SNAPSHOT.UtemezoService auto-timer?:true persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5ae465ae initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Mar 21 16:05:40 CET 2016 timerState=ACTIVE info=null] on EJB jelenteskezelo-1.0.0-SNAPSHOT.jelenteskezelo-1.0.0-SNAPSHOT.UtemezoService: java.lang.RuntimeException: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
[Server:server-one]
[Server:server-one] at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:421)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
[Server:server-one] at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
[Server:server-one] at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Server:server-one] Caused by: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
[Server:server-one]
[Server:server-one] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:447)
[Server:server-one] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
[Server:server-one] at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:951)
[Server:server-one] at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:513)
[Server:server-one] at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:227)
[Server:server-one] at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
[Server:server-one] at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:208)
[Server:server-one] at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1046)
[Server:server-one] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1336)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3613)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3694)
[Server:server-one] at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1354)
[Server:server-one] at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
[Server:server-one] at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:410)
[Server:server-one] ... 8 more
[Server:server-one]
{noformat}
> Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
> ----------------------------------------------------------------------
>
> Key: WFLY-6412
> URL: https://issues.jboss.org/browse/WFLY-6412
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: Linux, JDK8, Oracle DB 11g
> Reporter: Gábor Péntek
> Fix For: 8.2.0.Final, 10.0.0.Final
>
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the
> UPDATE JBOSS_EJB_TIMER..
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6412) Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
by Gábor Péntek (JIRA)
Gábor Péntek created WFLY-6412:
----------------------------------
Summary: Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
Key: WFLY-6412
URL: https://issues.jboss.org/browse/WFLY-6412
Project: WildFly
Issue Type: Bug
Components: EJB
Environment: Linux, JDK8, Oracle DB 11g
Reporter: Gábor Péntek
Fix For: 10.0.0.Final, 8.2.0.Final
If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the
UPDATE JBOSS_EJB_TIMER..
the other nodes throw an
ORA-08177: can't serialize access for this transaction
exception.
The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
The serialization exception is also thrown upon server/application startup sometimes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1009) lambda expressions cannot be parsed by ecj/janino
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1009?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1009:
-------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1199965|https://bugzilla.redhat.com/show_bug.cgi?id=1199965] from ON_QA to VERIFIED
> lambda expressions cannot be parsed by ecj/janino
> -------------------------------------------------
>
> Key: DROOLS-1009
> URL: https://issues.jboss.org/browse/DROOLS-1009
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.3.0.Final
> Reporter: Malte Brunnlieb
> Assignee: Mario Fusco
> Fix For: 6.4.0.Beta1
>
>
> Using Java8 lambda expression in the decision template like
> bean1.call(() -> $param);
> you will run into compiler issues with ejc as well as the currently supported version of JANINO (2.5.16). I tried to manually upgrade the JANINO compiler version, but got stuck in compatibility issues as the Scanner seems to have been changed regarding exception handling.
> Can you suggest to fix the incompatibility with JANINO > 2.5.16 such that lambda expressions can be parsed by the newest parsers? Would be nice :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month