[JBoss JIRA] (WFLY-3280) Thread locking problem when app server is going to shutdown
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-3280?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-3280:
----------------------------------------
I moved the bug under wildfly as I found that it's more appropriate.
> Thread locking problem when app server is going to shutdown
> ------------------------------------------------------------
>
> Key: WFLY-3280
> URL: https://issues.jboss.org/browse/WFLY-3280
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: David Lloyd
> Attachments: server.dump, server.log
>
>
> I face problem that remoting thread and MSC service thread is deadlocked when server is going to shutdown.
> This happens in half of the cases when I run my integration arquillian tests again EAP 6.3.0 engineering releases.
> I deploy one testing application packaged as jar file and then jdbc driver is deployed by copying to deployments folder.
> I'm attaching server log file and thread dump at the time when threads are stuck.
> I was trying to find out where the lock occurs and from the stack trace it happens on two places. One is lock on remoting queue and other is lock on DeploymentRepository object.
> I did a quick fix which seems to work for me that I removed 'synchronized' keyword from the methods which remove listeners in DeploymentRepository.
> It means from:
> https://github.com/jbossas/jboss-eap/blob/6.x/ejb3/src/main/java/org/jbos...
> and
> https://github.com/jbossas/jboss-eap/blob/6.x/ejb3/src/main/java/org/jbos...
> I'm really not sure whether this is 'a correct' fix but I just put my observation here to have some starting point.
> This could not be trouble in remoting directly, maybe it's rather problem of MSC component. If so, please, change the jira type. Thank you.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3280) Thread locking problem when app server is going to shutdown
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-3280?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka moved REM3-188 to WFLY-3280:
---------------------------------------------
Project: WildFly (was: Remoting 3)
Key: WFLY-3280 (was: REM3-188)
Affects Version/s: 8.1.0.CR1
(was: 3.3.1.Final)
Security: Public
> Thread locking problem when app server is going to shutdown
> ------------------------------------------------------------
>
> Key: WFLY-3280
> URL: https://issues.jboss.org/browse/WFLY-3280
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: David Lloyd
> Attachments: server.dump, server.log
>
>
> I face problem that remoting thread and MSC service thread is deadlocked when server is going to shutdown.
> This happens in half of the cases when I run my integration arquillian tests again EAP 6.3.0 engineering releases.
> I deploy one testing application packaged as jar file and then jdbc driver is deployed by copying to deployments folder.
> I'm attaching server log file and thread dump at the time when threads are stuck.
> I was trying to find out where the lock occurs and from the stack trace it happens on two places. One is lock on remoting queue and other is lock on DeploymentRepository object.
> I did a quick fix which seems to work for me that I removed 'synchronized' keyword from the methods which remove listeners in DeploymentRepository.
> It means from:
> https://github.com/jbossas/jboss-eap/blob/6.x/ejb3/src/main/java/org/jbos...
> and
> https://github.com/jbossas/jboss-eap/blob/6.x/ejb3/src/main/java/org/jbos...
> I'm really not sure whether this is 'a correct' fix but I just put my observation here to have some starting point.
> This could not be trouble in remoting directly, maybe it's rather problem of MSC component. If so, please, change the jira type. Thank you.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3226) Add test cases to verify LDAP caching on security realms.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3226?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-3226:
------------------------------------
Hi Darran,
have you any experience writnig interceptors for apache ds. Following the tutorial https://cwiki.apache.org/confluence/display/DIRxSRVx11/6.2.+Implementing+..., writing just some message to output, test LdapAuthenticationSuiteTest have been broken. Test was unable to login sucesfully. Is there any interceptor already in project I can look into?
Thanx
> Add test cases to verify LDAP caching on security realms.
> ---------------------------------------------------------
>
> Key: WFLY-3226
> URL: https://issues.jboss.org/browse/WFLY-3226
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Test Suite
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> The existing test cases are based on a statically defined set of LDIFs, testing of caching could consider a couple of options: -
> 1 - Interceptors within ApacheDS to verify if calls hit the directory.
> 2 - Updates to the directory that would affect the outcome of tests if there is a cache hit, tests can then be repeated with and without clearing the cache.
> Note: It would be beneficial for this to use different users and groups and maybe even different partitions so that test ordering does not affect the outcome if changes are made to the directory.
--
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
10 years, 5 months
[JBoss JIRA] (DROOLS-296) Drools date coercion and conditional OR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-296?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-296:
------------------------------------------------
Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1072217|https://bugzilla.redhat.com/show_bug.cgi?id=1072217] from NEW to ASSIGNED
> Drools date coercion and conditional OR
> ---------------------------------------
>
> Key: DROOLS-296
> URL: https://issues.jboss.org/browse/DROOLS-296
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 7
> Reporter: Madhura Jayaratne
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
>
> If I try a simple Drools rule with conditions on date type and uses conditional OR (||) I get the following error. If I change || to && it works fine.
> Condition
> $container: DateContainer( date >= "15-Oct-2013" || date <= "01-Oct-2013" )
> Error
> Unable to Analyse Expression date >= "15-Oct-2013" || date <= "01-Oct-2013":
> [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]
> [Near : {... date >= "15-Oct-2013" || date <= "01-Oct-2013" ....}]
> ^
> [Line: 9, Column: 1] : [Rule name='Test rule']
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-675) Link to Console missing from Welcome page
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-675?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-675.
-----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Won't Fix
The existing behavior is deliberate and I don't foresee us changing it, so I'm resolving this as Won't Fix.
> Link to Console missing from Welcome page
> -----------------------------------------
>
> Key: WFLY-675
> URL: https://issues.jboss.org/browse/WFLY-675
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Chuck Mosher
> Labels: eap6-ux
> Attachments: ConsoleWithLinkScreenshot.png, ConsoleWithoutLinkScreenshot.png
>
>
> If I start up the app server(s) using "bin/domain.sh", I can open up the starting page @ localhost:8080/ but there is no link to open the console; only to examine the documentation. The link to the Console is there when running standalone.sh. See attached screenshots.
> Options are: leave the link in there, but when clicked it will result in an error message instructing the user they need to pick which instance they want to examine. Or, point it to localhost:9990/.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3279?page=com.atlassian.jira.plugin.... ]
Mehboob Alam updated WFLY-3279:
-------------------------------
Description:
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
This behavior also appears to be different than that of java.net.URL,
public URL(URL context, String spec)
throws MalformedURLException
which states this: If the spec's path component begins with a slash character "/" then the path is treated as absolute and the spec path replaces the context path.
Otherwise, the path is treated as a relative path and is appended to the context path, as described in RFC2396. Also, in this case, the path is canonicalized through the removal of directory changes made by occurences of ".." and ".".
was:
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
> HttpServletResponse.sendRedirect() not working for relative URL
> ---------------------------------------------------------------
>
> Key: WFLY-3279
> URL: https://issues.jboss.org/browse/WFLY-3279
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Windows
> Reporter: Mehboob Alam
> Assignee: Stuart Douglas
> Attachments: Recreate_SendRedirect_Problem.ear
>
>
> I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
>
> The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
> To test this, I enter my app's URL like this-
> http://localhost:8080/helloworld/hello
> Then, inside the first servlet, I do a redirect -
> String url = "../goodbye/bye";
> response.sendRedirect(response.encodeRedirectURL(url));
> wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
> http://localhost:8080/goodbye/bye
> JBoss eap-6-1-0
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 200 localhost:8080 /goodbye/bye/
> WildFly 8.0 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 404 localhost:8080 /helloworld/
> WildFly 8.1.0 CR1 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 403 localhost:8080 /helloworld/
> This behavior also appears to be different than that of java.net.URL,
> public URL(URL context, String spec)
> throws MalformedURLException
> which states this: If the spec's path component begins with a slash character "/" then the path is treated as absolute and the spec path replaces the context path.
> Otherwise, the path is treated as a relative path and is appended to the context path, as described in RFC2396. Also, in this case, the path is canonicalized through the removal of directory changes made by occurences of ".." and ".".
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
Mehboob Alam created WFLY-3279:
----------------------------------
Summary: HttpServletResponse.sendRedirect() not working for relative URL
Key: WFLY-3279
URL: https://issues.jboss.org/browse/WFLY-3279
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.CR1, 8.0.0.Final
Environment: Windows
Reporter: Mehboob Alam
Assignee: Stuart Douglas
Attachments: Recreate_SendRedirect_Problem.ear
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3279?page=com.atlassian.jira.plugin.... ]
Mehboob Alam updated WFLY-3279:
-------------------------------
Attachment: Recreate_SendRedirect_Problem.ear
> HttpServletResponse.sendRedirect() not working for relative URL
> ---------------------------------------------------------------
>
> Key: WFLY-3279
> URL: https://issues.jboss.org/browse/WFLY-3279
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Windows
> Reporter: Mehboob Alam
> Assignee: Stuart Douglas
> Attachments: Recreate_SendRedirect_Problem.ear
>
>
> I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
>
> The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
> To test this, I enter my app's URL like this-
> http://localhost:8080/helloworld/hello
> Then, inside the first servlet, I do a redirect -
> String url = "../goodbye/bye";
> response.sendRedirect(response.encodeRedirectURL(url));
> wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
> http://localhost:8080/goodbye/bye
> JBoss eap-6-1-0
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 200 localhost:8080 /goodbye/bye/
> WildFly 8.0 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 404 localhost:8080 /helloworld/
> WildFly 8.1.0 CR1 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 403 localhost:8080 /helloworld/
--
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
10 years, 5 months