February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2156) COUNTER does not work with ForkChannel on an already connected main channel

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2156?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2156. ---------------------------- Resolution: Done > COUNTER does not work with ForkChannel on an already connected main channel > --------------------------------------------------------------------------- > > Key: JGRP-2156 > URL: https://issues.jboss.org/browse/JGRP-2156 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0, 3.6.13 > > > The following code doesn't work: > {code:java} > JChannel ch=new JChannel().connect("cluster"); > ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true, > ProtocolStack.Position.ABOVE, FRAG2.class, > new COUNTER()); > CounterService counter_service=new CounterService(fc); > fc.connect("ignore"); > Counter counter=counter_service.getOrCreateCounter("cntr", 0); > {code} > Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called. > SOLUTION: add view change processing in down(). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8043) Timer fails if transaction isolation set to SERIALIZABLE

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-8043?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated WFLY-8043: ----------------------------------- Summary: Timer fails if transaction isolation set to SERIALIZABLE (was: Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g) > Timer fails if transaction isolation set to SERIALIZABLE > -------------------------------------------------------- > > Key: WFLY-8043 > URL: https://issues.jboss.org/browse/WFLY-8043 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final, 10.0.0.Final > Environment: Linux, JDK8, Oracle DB 11g > Reporter: Wolf-Dieter Fink > > 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 (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6412) Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-6412?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink commented on WFLY-6412: ---------------------------------------- The same happen for any other database Here Postgres Stacktrace: Caused by: org.postgresql.util.PSQLException: ERROR: could not serialize access due to concurrent update at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2455) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2155) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:288) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:430) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:356) at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:168) at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:135) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.postgresql.ds.PGPooledConnection$StatementHandler.invoke(PGPooledConnection.java:423) at com.sun.proxy.$Proxy10.executeUpdate(Unknown Source) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:410) > 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 > Affects Versions: 8.2.0.Final, 10.0.0.Final > Environment: Linux, JDK8, Oracle DB 11g > Reporter: Gábor Péntek > > 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 (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8043) Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-8043: -------------------------------------- Summary: Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g Key: WFLY-8043 URL: https://issues.jboss.org/browse/WFLY-8043 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 8.2.0.Final, 10.0.0.Final Environment: Linux, JDK8, Oracle DB 11g Reporter: Wolf-Dieter Fink 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 (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1426) Remove CDI extension from drools-compiler

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1426?page=com.atlassian.jira.plugi... ] Maciej Swiderski commented on DROOLS-1426: ------------------------------------------ this impacts KIE Server on WebSphere (essentially it can be started) after upgrade of hibernate that requires javassist which the collides with WebSphere one that tries to bootstrap CDI which KIE Server does not use. So idea here is to move the CDI related class and extension file to separate jar so it does not affect applications that don't want to use CDI. > Remove CDI extension from drools-compiler > ----------------------------------------- > > Key: DROOLS-1426 > URL: https://issues.jboss.org/browse/DROOLS-1426 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Karel Suta > Assignee: Mario Fusco > Priority: Critical > Labels: reported-by-qe > Attachments: stacktrace.txt > > > CDI extension should be removed from drools-compiler [1] as it doesn't belong to core artifact. It can cause issues when deploying on various application servers like on WebSphere using Kie server - see attachment. > [1] https://github.com/droolsjbpm/drools/blob/7.0.0.Beta6/drools-compiler/src... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2156) COUNTER does not work with ForkChannel on an already connected main channel

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2156?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2156: -------------------------------- Unit test is ForkChannelTest.testCounterService() > COUNTER does not work with ForkChannel on an already connected main channel > --------------------------------------------------------------------------- > > Key: JGRP-2156 > URL: https://issues.jboss.org/browse/JGRP-2156 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0, 3.6.13 > > > The following code doesn't work: > {code:java} > JChannel ch=new JChannel().connect("cluster"); > ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true, > ProtocolStack.Position.ABOVE, FRAG2.class, > new COUNTER()); > CounterService counter_service=new CounterService(fc); > fc.connect("ignore"); > Counter counter=counter_service.getOrCreateCounter("cntr", 0); > {code} > Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called. > SOLUTION: add view change processing in down(). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2156) COUNTER does not work with ForkChannel on an already connected main channel

by Bela Ban (JIRA)

Bela Ban created JGRP-2156: ------------------------------ Summary: COUNTER does not work with ForkChannel on an already connected main channel Key: JGRP-2156 URL: https://issues.jboss.org/browse/JGRP-2156 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0, 3.6.13 The following code doesn't work: {code:java} JChannel ch=new JChannel().connect("cluster"); ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true, ProtocolStack.Position.ABOVE, FRAG2.class, new COUNTER()); CounterService counter_service=new CounterService(fc); fc.connect("ignore"); Counter counter=counter_service.getOrCreateCounter("cntr", 0); {code} Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called. SOLUTION: add view change processing in down(). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8042) JAVASERVERFACES-3936 / JAVASERVERFACES-3152 / JAVASERVERFACES-3035 - JSF ui:repeat losing state on ajax requests

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFLY-8042?page=com.atlassian.jira.plugin.... ] Panagiotis Sotiropoulos moved JBEAP-8697 to WFLY-8042: ------------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8042 (was: JBEAP-8697) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JSF (was: JSF) Target Release: (was: 7.1.0.GA) > JAVASERVERFACES-3936 / JAVASERVERFACES-3152 / JAVASERVERFACES-3035 - JSF ui:repeat losing state on ajax requests > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8042 > URL: https://issues.jboss.org/browse/WFLY-8042 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Panagiotis Sotiropoulos > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ] Tomas Hofman edited comment on JBJCA-1338 at 2/7/17 5:06 AM: ------------------------------------------------------------- PR with a suggested solution: https://github.com/ironjacamar/ironjacamar/pull/602 was (Author: thofman): PR with a suggested solution. > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-1338 > URL: https://issues.jboss.org/browse/JBJCA-1338 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.2.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ] Tomas Hofman commented on WFLY-8032: ------------------------------------ I sent a PR with a suggested solution: https://github.com/ironjacamar/ironjacamar/pull/602 > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8032 > URL: https://issues.jboss.org/browse/WFLY-8032 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Tomas Hofman > Assignee: Stefano Maestri > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017