October 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-13941) Failed to persist session attribute with Websocket endpoints

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-13941?page=com.atlassian.jira.plugi... ] Parul Sharma commented on WFLY-13941: ------------------------------------- [~flavia.rainone] are you working on this issue? > Failed to persist session attribute with Websocket endpoints > ------------------------------------------------------------ > > Key: WFLY-13941 > URL: https://issues.redhat.com/browse/WFLY-13941 > Project: WildFly > Issue Type: Bug > Components: Web Sockets > Affects Versions: 13.0.0.Final > Reporter: Abi Sarwan > Assignee: Flavia Rainone > Priority: Major > Attachments: mavenproject1-1.0.war > > > When WildFly is configured to persist sessions (standalone mode) during restart/redeploy and contains a websocket endpoint, a NotSerializableException is thrown: > Failed to persist session attribute io.undertow.websocket.current-connections with value [WebSocket13Channel peer /127.0.0.1:64853 local /127.0.0.1:8080[ No Receiver [] -- [] -- []]] for session xxxxxxxx: java.io.NotSerializableException: io.undertow.websockets.core.protocol.version13.WebSocket13Channel > > This start to happen in wildfly 13. The deployment works fine in wildfly 12. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-149) Fix unstable test 'FlushTests#modeLeak'

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-149?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-149. ---------------------------- > Fix unstable test 'FlushTests#modeLeak' > --------------------------------------- > > Key: AG-149 > URL: https://issues.redhat.com/browse/AG-149 > Project: Agroal > Issue Type: Bug > Components: test > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 1.9 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-151) Turn on signature check on agroal-api module

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-151?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-151. ---------------------------- > Turn on signature check on agroal-api module > -------------------------------------------- > > Key: AG-151 > URL: https://issues.redhat.com/browse/AG-151 > Project: Agroal > Issue Type: Task > Components: api, build > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.9 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-143) Add s flush mode to forcefully remove leaked connections

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-143?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-143. ---------------------------- > Add s flush mode to forcefully remove leaked connections > -------------------------------------------------------- > > Key: AG-143 > URL: https://issues.redhat.com/browse/AG-143 > Project: Agroal > Issue Type: Bug > Components: api, pool > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.9 > > > When there is a notification of a leaking connection there is no way to remove that connection from the pool. In the event of uncommon connection leaks, these will accumulate over time, eventually blocking the pool. Using the existing mechanism for flush operations, add a new mode to allow the removal of these connections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-141) Fix availableCount in pool-less

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-141?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-141. ---------------------------- > Fix availableCount in pool-less > ------------------------------- > > Key: AG-141 > URL: https://issues.redhat.com/browse/AG-141 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.9 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-140) Connection leak caused by failed transaction integration

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-140?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-140. ---------------------------- > Connection leak caused by failed transaction integration > -------------------------------------------------------- > > Key: AG-140 > URL: https://issues.redhat.com/browse/AG-140 > Project: Agroal > Issue Type: Bug > Components: narayana, pool > Affects Versions: 1.8 > Reporter: Dmitry Telegin > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.9 > > Attachments: agroal-connection-leak-poc.log > > > If the following conditions are met: > - transaction integration is installed; > - connection checkout has been successful; > - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception, > then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion. > The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active): > {code:java} > Foo foo = new Foo(); > try { > em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted > } catch (Exception e) { > // suppress exception > LOG.log(Level.WARNING, "merge", e); > } > > // continue using the same EntityManager > em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked > {code} > Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager afterwards), but it shouldn't lead to connection leaks either. > The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-145. ---------------------------- > Active waiting deadlock in StampedCopyOnWriteArrayList > ------------------------------------------------------ > > Key: AG-145 > URL: https://issues.redhat.com/browse/AG-145 > Project: Agroal > Issue Type: Bug > Affects Versions: 1.8 > Reporter: Rene Böing > Assignee: Luis Barreiro > Priority: Critical > Fix For: 1.9 > > Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png > > > While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object. > > A simple reproducer in junit (fails nearly every time on my machine): > > {code:java} > @Test > public void testThis() { > ExecutorService service = Executors.newFixedThreadPool(10); > StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class); > Object o = new Object(); > list.add(new Object()); > list.add(new Object()); > list.add(new Object()); > list.add(new Object()); > list.add(o); > list.add(new Object()); > List<Runnable> runnerList = new ArrayList<>(10); > List<Future> futureList = new ArrayList<>(10); > for (int i = 0; i < 10; i++) { > runnerList.add(new Runnable() { > @Override > public void run() { > list.remove(o); > System.out.println("Removed success!"); > } > }); > } > for (Runnable r : runnerList) { > futureList.add(service.submit(r)); > } > for (Future r : futureList) { > try { > r.get(10000, TimeUnit.MILLISECONDS); > } catch (InterruptedException e) { > e.printStackTrace(); > } catch (ExecutionException e) { > e.printStackTrace(); > } catch (TimeoutException e) { > System.out.println("Seems like we have a deadlock!"); > } > } > } > {code} > > Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter > <property name="hibernate.agroal.maxLifetime_m">60</property> > If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path: > !image-2020-07-31-08-39-28-630.png! > > The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation: > !image-2020-07-31-08-40-41-968.png! > > Kind regards, > Rene -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-142) Remove info message when setting empty AgroalPoolInterceptors

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-142?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-142. ---------------------------- > Remove info message when setting empty AgroalPoolInterceptors > ------------------------------------------------------------- > > Key: AG-142 > URL: https://issues.redhat.com/browse/AG-142 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 1.9 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-148) Run all tests in CI

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-148?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-148. ---------------------------- > Run all tests in CI > -------------------- > > Key: AG-148 > URL: https://issues.redhat.com/browse/AG-148 > Project: Agroal > Issue Type: Task > Components: build > Affects Versions: 1.8 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Minor > Fix For: 1.9 > > > Currently, some groups don't run by default -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (AG-144) PreparedStatement setObject variations are missing from wrapper

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-144?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro closed AG-144. ---------------------------- > PreparedStatement setObject variations are missing from wrapper > --------------------------------------------------------------- > > Key: AG-144 > URL: https://issues.redhat.com/browse/AG-144 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 1.7, 1.8 > Reporter: Kevin Wooten > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.9 > > > `PreparedStatementWrapper` doesn't implement the following variations of `PreparedStatement.setObject`.: > void setObject(int parameterIndex, Object x, SQLType targetSqlType) > void setObject(int parameterIndex, Object x, SQLType targetSqlType, int scaleOrLength) > NOTE: These are the `SQLType` variations and not the `int targetSqlType` variations (which are implemented) -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020