[JBoss JIRA] (JBAS-9539) ${jdbc.maxPoolSize} value in *-ds.xml file always read as 0 in JBOSS 6.1
by Karthick Narayanan (JIRA)
[ https://issues.jboss.org/browse/JBAS-9539?page=com.atlassian.jira.plugin.... ]
Karthick Narayanan commented on JBAS-9539:
------------------------------------------
It looks like the fix is the following changeset which was already fixed in JBOSS 5.1 patch but didn't made to JBOSS 6.1 final version.
https://source.jboss.org/changelog/JBossAS6?cs=109885
Can we have this patch added to JBOSS 6.1-final?
> ${jdbc.maxPoolSize} value in *-ds.xml file always read as 0 in JBOSS 6.1
> ------------------------------------------------------------------------
>
> Key: JBAS-9539
> URL: https://issues.jboss.org/browse/JBAS-9539
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: 6.1.0
> Environment: CentOS/Windows
> Reporter: Karthick Narayanan
> Assignee: Jesper Pedersen
> Labels: regression
>
> I’ve recently started using JBoss 6.1.0 and ran into an issue with setting min and max pool size in oracle-ds.xml. I tried two approaches (for both max and min pool size):
> 1. as a hardcoded number like <max-pool-size>5</max-pool-size>
> 2. as a configurable variable like <max-pool-size>${jdbc.maxPoolSize}</max-pool-size>
> While the first approach worked fine the second one didn't. When the max and min pool sizes were set as configurable variables, the Java.sql.DataSource object created had max-pool-size=0 and min-pool-size=0. All the other settings (being set as configurable variables) in the same xml config file worked as expected. When I did further investigation I found that,
> Org.jboss.resource.deployers.ManagedConnectionFactoryParserDeployer class reads all the oracle*-ds.xml files and sets the max/min pool size values to 0 even though I specified <max-pool-size>${jdbc.maxPoolSize}</max-pool-size>. It is not going and reading the value from the property file.
> This had been working fine in JBoss 4.2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-1634?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento updated JGRP-1634:
---------------------------------------------
Attachment: jgroups.xml
> LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1634
> URL: https://issues.jboss.org/browse/JGRP-1634
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Environment: JGroups 3.3.0 Final
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Attachments: jgroups.xml
>
>
> We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are:
> (a) tryLock() randomly hangs
> (b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node)
> This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using.
> 3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be:
> (i) OOB used for lock messages. This should not be causing problems.
> (ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems.
> (iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring.
> The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks:
> - handleLockRequest()
> - handleAwaitRequest()
> - handleDeleteAwaitRequest()
> - handleSignalRequest()
> This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems.
> I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
by Manuel Dominguez Sarmiento (JIRA)
Manuel Dominguez Sarmiento created JGRP-1634:
------------------------------------------------
Summary: LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
Key: JGRP-1634
URL: https://issues.jboss.org/browse/JGRP-1634
Project: JGroups
Issue Type: Bug
Affects Versions: 3.3
Environment: JGroups 3.3.0 Final
Reporter: Manuel Dominguez Sarmiento
Assignee: Bela Ban
We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are:
(a) tryLock() randomly hangs
(b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node)
This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using.
3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be:
(i) OOB used for lock messages. This should not be causing problems.
(ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems.
(iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring.
The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks:
- handleLockRequest()
- handleAwaitRequest()
- handleDeleteAwaitRequest()
- handleSignalRequest()
This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems.
I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (WFLY-1361) WeldListener throws JBAS016071: Singleton not set for ModuleClassLoader during application undeployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1361?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1361.
----------------------------------
Fix Version/s: 8.0.0.Alpha2
Resolution: Done
> WeldListener throws JBAS016071: Singleton not set for ModuleClassLoader during application undeployment
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1361
> URL: https://issues.jboss.org/browse/WFLY-1361
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> Testing some of the quickstarts against WildFly upstream, I see this exception during application undeployment for many application:
> {code}
> 14:58:56,111 WARN [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000004: Failure during stop of service jboss.undertow.deployment.default-host./jboss-as-ejb-throws-exception-web: java.lang.IllegalStateException: JBAS016071: Singleton not set for ModuleClassLoader for Module "org.wildfly.extension.undertow:main" from local module loader @294944 (finder: local module finder @8923f5 (roots: /jbossas/as7/wildfly/build/target/wildfly-8.0.0.Alpha1-SNAPSHOT/modules,/jbossas/as7/wildfly/build/target/wildfly-8.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.weld.Container.instance(Container.java:54)
> at org.jboss.weld.context.http.HttpSessionContextImpl.getConversationContext(HttpSessionContextImpl.java:63)
> at org.jboss.weld.context.http.HttpSessionContextImpl.destroy(HttpSessionContextImpl.java:39)
> at org.jboss.weld.servlet.WeldListener.sessionDestroyed(WeldListener.java:128)
> at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:215)
> at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:38)
> at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:38)
> at io.undertow.server.session.InMemorySessionManager.stop(InMemorySessionManager.java:61)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:659)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:90)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2082) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2043) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {code}
> I haven't yet investigated what the problem is. It doesn't seem to be causing any problems except for this log. An example quickstart to test is here https://github.com/jaikiran/quickstart/tree/wildfly-upgrade/greeter (start the server, deploy that app and then stop the server to see that exception log)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1376.
----------------------------------
Fix Version/s: 8.0.0.Alpha2
Resolution: Done
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month