[JBoss JIRA] (JBJCA-1276) Prefill race condition in flush
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1276?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1276:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1231658|https://bugzilla.redhat.com/show_bug.cgi?id=1231658] from VERIFIED to CLOSED
> Prefill race condition in flush
> -------------------------------
>
> Key: JBJCA-1276
> URL: https://issues.jboss.org/browse/JBJCA-1276
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.31.Final, 1.1.9.Final
> Reporter: Takayoshi Kimura
> Assignee: Jesper Pedersen
> Fix For: 1.0.33.Final
>
> Attachments: server.log
>
>
> There is a race condition between AbstractPool and SemaphoreArrayListManagedConnectionPool.
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> AbstractPool flushes the mcp, mcp invokes PoolFiller which works in a separate thread. However AbstractPool is going to unregister the empty mcp and this mcp is no longer used. Then the dead mcp is prefilled in a separate thread by PoolFiller.
> At next getConnection(), the mcp is re-initialized and prefilled.
> I've attached logs, prefill enabled and min-size is 10. Boot server, invoke flush-all-connection-in-pool, getConnection() then killed. The prefill is done 3 times where it should be twice.
> {noformat}
> 16:26:04,254 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) ExampleDS: flush(true)
> 16:26:04,255 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) Destroying flushed connection org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1d298ed8[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@4ae26a1b connection handles=0 lastUse=1434353148384 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@379ba3b3[connectionListener=1d298ed8 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:02:20,666 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 7) Shutdown - Pool: ExampleDS MCP: 2f5a2102
> 16:02:20,666 TRACE [org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory] (JCA PoolFiller) Using properties: {user=sa, password=--hidden--}
> 16:02:20,666 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (management-handler-thread - 7) Unregister pool: SemaphoreArrayListManagedConnectionPool@2f5a2102[pool=ExampleDS]
> 16:26:04,259 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@34f0bb27[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@288f1898 connection handles=0 lastUse=1434353164259 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@4a97b7f5[connectionListener=34f0bb27 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:26:11,342 TRACE [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http-/127.0.0.1:8080-1) getManagedConnection interleaving=false , tx=null
> 16:26:11,343 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (http-/127.0.0.1:8080-1) Register pool: SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] (interval=1800000)
> 16:26:11,344 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1c706b4d[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@18949ad1 connection handles=0 lastUse=1434353171343 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] xaResource=LocalXAResourceImpl@44401bf2[connectionListener=1c706b4d connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> {noformat}
> In 1.0.31.Final:
> > if (mcp.isEmpty())
> > clearMcpPools.add(mcp);
> In 1.2 branch it looks like already fixed within commit 956af09c8494d4187db24a253e7e37b5ba5d9779 for JBJCA-1135:
> > if (mcp.isEmpty() && !isPrefill() && size > 1)
> > clearMcpPools.add(mcp);
> We probably need to backport "!isPrefill()" to the 1.0/1.1 branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1752:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1215786|https://bugzilla.redhat.com/show_bug.cgi?id=1215786] from VERIFIED to CLOSED
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Labels: 621
> Fix For: 3.2.14, 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5154) DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFLY-5154?page=com.atlassian.jira.plugin.... ]
Jan Tymel closed WFLY-5154.
---------------------------
Resolution: Done
This issue is no longer valid. Feel free to reopen if this issue occurs again in the future.
> DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5154
> URL: https://issues.jboss.org/browse/WFLY-5154
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Jan Tymel
> Fix For: 10.0.0.CR2
>
> Attachments: GrantModulePermissionsTestCase.stacktrace.txt
>
>
> *Description of problem*
> * org.jboss.as.testsuite.integration.secman.module.DenyModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-deny.jar
> * org.jboss.as.testsuite.integration.secman.module.GrantModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-grant.jar
> * org.jboss.as.testsuite.integration.secman.module.LimitedModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-limited.jar
> *How reproducible*
> * 15%
> * OpenJDK, IBM JDK, Oracle JDK
> * Solaris, Windows, RHEL
>
> *Expected results*
> No failures in test case.
> *Additional info*
> See for server logs for DenyModulePermissionsTestCase in attachment
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7754) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-7754?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-7754:
------------------------------------
Solution is to:
stop wildfly
rm -v wildfly-10.1.0.Final/standalone/data/infinispan/web/*.dat
> WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
> ----------------------------------------------------------------------------
>
> Key: WFLY-7754
> URL: https://issues.jboss.org/browse/WFLY-7754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
>
> When modifying the WELD bean profile between starting/stopping WildFly with persistent session cookies over restart enabled.
> It is possible to get an unrecoverable o.j.w.e.IllegalStateException.
> What I mean by this is that if the AS knows the HTTP session cookie is a valid ID, but is unable to recover it from the persistence serialization over a restart (due to a change in the WELD BeanIdentifer instances changing to allow the optimization to work in this area). What the AS should do is simply log the problem and invalidate the session cookie completely. All this should happen in a transparent way to the WebApp, so it gets a null return or a brand new HttpSession.
> This will automatically allow the HTTP client to recover, by forcing the application to generate a new HTTP session as necessary / or force logout, etc..
> This is unrecoverable since the exception seems to be thrown at a level before it hits any WebApp application code. So it doesn't seem possible for the WebApp developer to correct the problem from the exception. Which makes sense since you need a HttpSession object to invoke #invalidate() on and it is recovering that that is.
> Everytime the user refreshes all they get is the error and a HTTP/500 Internal Server Error and the user has to either delete their cookie, or the WildFly admin shutdown and remove any persistent session cookie data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-774) Memory leak in JBoss CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-774?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-774:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1232736|https://bugzilla.redhat.com/show_bug.cgi?id=1232736] from CLOSED to VERIFIED
> Memory leak in JBoss CLI
> ------------------------
>
> Key: WFCORE-774
> URL: https://issues.jboss.org/browse/WFCORE-774
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Tomas Hofman
> Fix For: 2.0.0.Alpha8
>
>
> The JBoss CLI contains a memory leak related to CLI Kerberos authentication.
> The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor,
> which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}.
> It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered
> configurations.
> Moreover, the searches for appropriate
> login config take more and more time because they have to go through all the wrapped objects.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-774) Memory leak in JBoss CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-774?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-774:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1232736|https://bugzilla.redhat.com/show_bug.cgi?id=1232736] from VERIFIED to CLOSED
> Memory leak in JBoss CLI
> ------------------------
>
> Key: WFCORE-774
> URL: https://issues.jboss.org/browse/WFCORE-774
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Tomas Hofman
> Fix For: 2.0.0.Alpha8
>
>
> The JBoss CLI contains a memory leak related to CLI Kerberos authentication.
> The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor,
> which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}.
> It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered
> configurations.
> Moreover, the searches for appropriate
> login config take more and more time because they have to go through all the wrapped objects.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7754) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-7754?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-7754:
------------------------------------
ERROR [io.undertow.request] (default task-41) UT005023: Exception handling request to /main/systema/process.cgi:
org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key
SessionCreationMetaDataKey(-FZZqY7ngjgP3-RbfmHcXh-2NWGA2HIPaxcumCPy) and requestor GlobalTransaction:<null>:7:local. Lock is held by GlobalTransaction:<null>:3:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:238)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:193)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:193)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:116)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:80)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:38)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:233)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:148)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:772)
at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:234)
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
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)
> WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
> ----------------------------------------------------------------------------
>
> Key: WFLY-7754
> URL: https://issues.jboss.org/browse/WFLY-7754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
>
> When modifying the WELD bean profile between starting/stopping WildFly with persistent session cookies over restart enabled.
> It is possible to get an unrecoverable o.j.w.e.IllegalStateException.
> What I mean by this is that if the AS knows the HTTP session cookie is a valid ID, but is unable to recover it from the persistence serialization over a restart (due to a change in the WELD BeanIdentifer instances changing to allow the optimization to work in this area). What the AS should do is simply log the problem and invalidate the session cookie completely. All this should happen in a transparent way to the WebApp, so it gets a null return or a brand new HttpSession.
> This will automatically allow the HTTP client to recover, by forcing the application to generate a new HTTP session as necessary / or force logout, etc..
> This is unrecoverable since the exception seems to be thrown at a level before it hits any WebApp application code. So it doesn't seem possible for the WebApp developer to correct the problem from the exception. Which makes sense since you need a HttpSession object to invoke #invalidate() on and it is recovering that that is.
> Everytime the user refreshes all they get is the error and a HTTP/500 Internal Server Error and the user has to either delete their cookie, or the WildFly admin shutdown and remove any persistent session cookie data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months