[JBoss JIRA] (WFLY-4435) Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4435?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4435:
---------------------------------
Summary: Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added" (was: Mixed domain tests fail on infinispan/jgroups subsystems)
> Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added"
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4435
> URL: https://issues.jboss.org/browse/WFLY-4435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The same problem happens when attempting to use 2_0 version of these subsystems in current configuration.
> {noformat}
> [Host Controller] [0m[0m15:33:41,155 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[0m15:33:41,161 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-clustered-sfsb-cache is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[31m15:33:41,174 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([[0m
> [Host Controller] [31m ("profile" => "full-ha"),[0m
> [Host Controller] [31m ("subsystem" => "jgroups"),[0m
> [Host Controller] [31m ("channel" => "server")[0m
> [Host Controller] [31m]) - failure description: "WFLYCTL0175: Resource [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\")[0m
> [Host Controller] [31m] does not exist; a resource at address [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\"),[0m
> [Host Controller] [31m (\"channel\" => \"server\")[0m
> [Host Controller] [31m] cannot be created until all ancestor resources have been added"[0m
> [Host Controller] [31m[0m[31m15:33:41,183 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.[0m
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
by Joseph Hwang (JIRA)
[ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.... ]
Joseph Hwang commented on WFLY-3659:
------------------------------------
You mean I have to make another jira about this issue to Elytron? and have to wait again until fix version WildFly 10?
> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3659
> URL: https://issues.jboss.org/browse/WFLY-3659
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Joseph Hwang
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> == web.xml
> <security-role>
> <role-name>administrator</role-name>
> </security-role>
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
> <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
> <module-option name="principalsQuery" value="select password from credential where uid=?"/>
> <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="RFC2617"/>
> <module-option name="hashUserPassword" value="false"/>
> <module-option name="hashStorePassword" value="true"/>
> <module-option name="passwordIsA1Hash" value="true"/>
> <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
> <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
> </login-module>
> </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> String userName="admin";
> String realmName="WildFly8DigestRealm";
> String password="passwd123";
> String clearTextPassword=userName+":"+realmName+":"+password;
> String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword);
> System.out.println("clearTextPassword: "+clearTextPassword);
> System.out.println("hashedPassword: "+hashedPassword);
> }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
> at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> ... 49 more
> This cofiguration worked well in JBoss AS 7.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04
by Dennis Gesker (JIRA)
[ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.... ]
Dennis Gesker updated WFLY-4570:
--------------------------------
Steps to Reproduce:
Set variables in JBOSS_HOME/bin/init.d/wildfly.conf
ln -s JBOSS_HOME/bin/init.d/wildfly.conf /etc/default/wildfly
ln -s JBOSS_HOME/bin/init.d/wildfly-init-debian.sh /etc/init.d/wildfly
cd /etc/init.d
update-rc.d wildfly defaults
permissions and user/group are of course set to wildfly.wildfly
was:
Set variables in JBOSS_HOME/bin/init.d/wildfly.conf
ln -s JBOSS_HOME/bin/init.d/wildfly.conf /etc/default/wildfly
JBOSS_HOME/bin/init.d/wildfly-init-debian.sh /etc/init.d/wildfly
cd /etc/init.d
update-rc.d wildfly defaults
permissions and user/group are of course set to wildfly.wildfly
> wildfly-init-debian.sh fails on Ubuntu 15.04
> --------------------------------------------
>
> Key: WFLY-4570
> URL: https://issues.jboss.org/browse/WFLY-4570
> Project: WildFly
> Issue Type: Bug
> Components: ConfigAdmin
> Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
> Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
> Reporter: Dennis Gesker
> Assignee: Thomas Diesler
> Priority: Minor
> Fix For: 9.0.0.CR1
>
>
> Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
> Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
> Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04
by Dennis Gesker (JIRA)
Dennis Gesker created WFLY-4570:
-----------------------------------
Summary: wildfly-init-debian.sh fails on Ubuntu 15.04
Key: WFLY-4570
URL: https://issues.jboss.org/browse/WFLY-4570
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
Reporter: Dennis Gesker
Assignee: Thomas Diesler
Priority: Minor
Fix For: 9.0.0.CR1
Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S edited comment on WFLY-4561 at 4/28/15 3:57 PM:
-------------------------------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when an InputStream is closed with unread data.
was (Author: marks1900):
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S edited comment on WFLY-4561 at 4/28/15 3:57 PM:
-------------------------------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when a InputStream is closed with unread data.
was (Author: marks1900):
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning that when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S commented on WFLY-4561:
------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning that when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-313:
------------------------------------
We do have some extra info on OperationDefinition that tells us what are parameters and what are reply attributes.
And it also know how to handle deprecated attributes.
> DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-313
> URL: https://issues.jboss.org/browse/WFCORE-313
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription.
> A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (DROOLS-776) Deadlock trying to synchronize 'eager' field in DefaultAgenda (between drools-worker thread and other)
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-776?page=com.atlassian.jira.plugin... ]
Juan Carlos Garcia updated DROOLS-776:
--------------------------------------
Summary: Deadlock trying to synchronize 'eager' field in DefaultAgenda (between drools-worker thread and other) (was: Deadlock trying to synchronize 'eager' field in DefaultAgenda (drools-worker thread and the other thread))
> Deadlock trying to synchronize 'eager' field in DefaultAgenda (between drools-worker thread and other)
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-776
> URL: https://issues.jboss.org/browse/DROOLS-776
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.2.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mark Proctor
>
> Migrating from drools 6.0.1.Final to 6.2.0.Final there seems to be a rare deadlock trying to synchronize the DefaultAgenda *eager* field, i have seen it only 2 or three times now as it seems very dificult to reproduce.
> In our scenario the test is calling *kSession.fireUntilHalt()* in a new thread, then in the main thread waiting for some events to happens (by calling in a loop: kSession.getObjects(new ClassObjectFilter(_clazz)))) and then doing some other assert checks.
> See the stacktrace i took with jstack:
> {code}
> Java stack information for the threads listed above:
> ===================================================
> "Thread-5":
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:92)
> - waiting to lock <0x00000000ff245780> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:1044)
> - locked <0x00000000ff3dab38> (a org.drools.core.util.LinkedList)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:996)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1258)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1333)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1310)
> at bar.foo.AIDelayTest$1.run(AIDelayTest.java:101)
> at java.lang.Thread.run(Thread.java:745)
> "drools-worker-2":
> at org.drools.core.common.DefaultAgenda.addEagerRuleAgendaItem(DefaultAgenda.java:287)
> - waiting to lock <0x00000000ff3dab38> (a org.drools.core.util.LinkedList)
> at org.drools.core.reteoo.PathMemory.queueRuleAgendaItem(PathMemory.java:159)
> at org.drools.core.reteoo.PathMemory.doUnlinkRule(PathMemory.java:133)
> - locked <0x00000000ff2457a0> (a org.drools.core.reteoo.PathMemory)
> at org.drools.core.reteoo.PathMemory.unlinkedSegment(PathMemory.java:173)
> at org.drools.core.reteoo.SegmentMemory.unlinkNode(SegmentMemory.java:203)
> at org.drools.core.reteoo.BetaMemory.unlinkNode(BetaMemory.java:100)
> at org.drools.core.reteoo.BetaNode.doDeleteRightTuple(BetaNode.java:377)
> at org.drools.core.reteoo.JoinNode.retractRightTuple(JoinNode.java:107)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:345)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:337)
> at org.drools.core.reteoo.EntryPointNode.retractObject(EntryPointNode.java:381)
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:615)
> at org.drools.core.base.DefaultKnowledgeHelper.delete(DefaultKnowledgeHelper.java:495)
> at org.drools.core.base.DefaultKnowledgeHelper.retract(DefaultKnowledgeHelper.java:486)
> at bar.foo.Rule_basic$u46$delayExecution$u46$01246876731.defaultConsequence(Rule_basic$u46$delayExecution$u46$01246876731.java:7)
> at bar.foo.Rule_basic$u46$delayExecution$u46$01246876731DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at bar.foo.Rule_basic$u46$delayExecution$u46$01246876731DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1114)
> - locked <0x00000000ff3da978> (a org.drools.core.common.DefaultAgenda)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:160)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:112)
> - locked <0x00000000ff245780> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.phreak.PhreakTimerNode$Executor.qevauateAndFireRule(PhreakTimerNode.java:485)
> at org.drools.core.phreak.PhreakTimerNode$TimerNodeJob$1.run(PhreakTimerNode.java:420)
> 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)
> Found 1 deadlock.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months