[JBoss JIRA] (WFLY-11565) WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
by Deepak Sahu (Jira)
[ https://issues.jboss.org/browse/WFLY-11565?page=com.atlassian.jira.plugin... ]
Deepak Sahu commented on WFLY-11565:
------------------------------------
Hi [~baranowb]
Any update on this issue?
> WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11565
> URL: https://issues.jboss.org/browse/WFLY-11565
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Final
> Reporter: Deepak Sahu
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: API.war
>
>
> I am using WildFly Server 9.0.0 Final, Javax ws, Jersey for developing Rest APIs. For all the responses whose httpStatus code is 204, the wildfly server adds Transfer encoding Chunked in the response header, which is not correct as per the Rest Standards. Because of this behavior some of the RestAPI clients hang, as they keep waiting for the response (which is not at all there).
> To verify the issue, I tried the same with Springboot instead of deploying the war in WildFly and the Response Header was not added with Transfer Encoding Chuncked.
> Let me know if some other information is required to fix this issue, if this is already fixed is there any patch for this issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11706) Deadlock in cleanup following DatabaseCertLoginModuleTestCase
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11706?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11706:
------------------------------------
Attachment: hang.txt
> Deadlock in cleanup following DatabaseCertLoginModuleTestCase
> -------------------------------------------------------------
>
> Key: WFLY-11706
> URL: https://issues.jboss.org/browse/WFLY-11706
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Brian Stansberry
> Assignee: Tom Jenkinson
> Priority: Critical
> Attachments: hang.txt
>
>
> A test hung due to a server-side deadlock.
> https://ci.wildfly.org/viewLog.html?buildId=139407&buildTypeId=WFPR&tab=b...
> Build log output stopped at this point:
> [18:27:07][Step 2/3] [INFO] Running org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase
> [18:27:42][Step 2/3] [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.744 s - in org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase
> [18:27:43][Step 2/3] [INFO] Running org.jboss.as.test.manualmode.web.ssl.DatabaseCertLoginModuleTestCase
> The 'main' thread of the test shows the test was shutting down the server:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0xf6507c00 nid=0x205c in Object.wait() [0xf667d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xc807a168> (a java.lang.UNIXProcess)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
> - locked <0xc807a168> (a java.lang.UNIXProcess)
> at org.wildfly.core.launcher.ProcessHelper.destroyProcess(ProcessHelper.java:60)
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.stopInternal(ManagedDeployableContainer.java:294)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.stop(CommonDeployableContainer.java:135)
> at org.jboss.arquillian.container.impl.ContainerImpl.stop(ContainerImpl.java:217)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:178)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:172)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.stopContainer(ContainerLifecycleController.java:171)
> {code}
> The server-side thread dump shows the hang:
> {code}
> Found one Java-level deadlock:
> =============================
> "Periodic Recovery":
> waiting to lock monitor 0xbcc6dbc0 (object 0xc8f80918, a java.util.concurrent.atomic.AtomicInteger),
> which is held by "ServerService Thread Pool -- 8"
> "ServerService Thread Pool -- 8":
> waiting to lock monitor 0xc1a6ffc8 (object 0xc8f64470, a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule),
> which is held by "Periodic Recovery"
> Java stack information for the threads listed above:
> ===================================================
> "Periodic Recovery":
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088)
> - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240)
> - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> "ServerService Thread Pool -- 8":
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119)
> - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule)
> - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63)
> at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66)
> - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Found 1 deadlock.
> {code}
> I'll attach the full thread dump.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11706) Deadlock in cleanup following DatabaseCertLoginModuleTestCase
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11706:
---------------------------------------
Summary: Deadlock in cleanup following DatabaseCertLoginModuleTestCase
Key: WFLY-11706
URL: https://issues.jboss.org/browse/WFLY-11706
Project: WildFly
Issue Type: Bug
Components: Test Suite, Transactions
Reporter: Brian Stansberry
Assignee: Tom Jenkinson
A test hung due to a server-side deadlock.
https://ci.wildfly.org/viewLog.html?buildId=139407&buildTypeId=WFPR&tab=b...
Build log output stopped at this point:
[18:27:07][Step 2/3] [INFO] Running org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase
[18:27:42][Step 2/3] [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.744 s - in org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase
[18:27:43][Step 2/3] [INFO] Running org.jboss.as.test.manualmode.web.ssl.DatabaseCertLoginModuleTestCase
The 'main' thread of the test shows the test was shutting down the server:
{code}
"main" #1 prio=5 os_prio=0 tid=0xf6507c00 nid=0x205c in Object.wait() [0xf667d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xc807a168> (a java.lang.UNIXProcess)
at java.lang.Object.wait(Object.java:502)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
- locked <0xc807a168> (a java.lang.UNIXProcess)
at org.wildfly.core.launcher.ProcessHelper.destroyProcess(ProcessHelper.java:60)
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.stopInternal(ManagedDeployableContainer.java:294)
at org.jboss.as.arquillian.container.CommonDeployableContainer.stop(CommonDeployableContainer.java:135)
at org.jboss.arquillian.container.impl.ContainerImpl.stop(ContainerImpl.java:217)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:178)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:172)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.stopContainer(ContainerLifecycleController.java:171)
{code}
The server-side thread dump shows the hang:
{code}
Found one Java-level deadlock:
=============================
"Periodic Recovery":
waiting to lock monitor 0xbcc6dbc0 (object 0xc8f80918, a java.util.concurrent.atomic.AtomicInteger),
which is held by "ServerService Thread Pool -- 8"
"ServerService Thread Pool -- 8":
waiting to lock monitor 0xc1a6ffc8 (object 0xc8f64470, a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule),
which is held by "Periodic Recovery"
Java stack information for the threads listed above:
===================================================
"Periodic Recovery":
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088)
- waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240)
- locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
"ServerService Thread Pool -- 8":
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119)
- waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule)
- locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger)
at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129)
at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63)
at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66)
- locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Found 1 deadlock.
{code}
I'll attach the full thread dump.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Edson Tirelli closed DROOLS-1825.
---------------------------------
Resolution: Won't Do
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam, drools-tools, verifier
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11275) JSF ViewMap Regression
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-11275?page=com.atlassian.jira.plugin... ]
Farah Juma updated WFLY-11275:
------------------------------
Git Pull Request: https://github.com/jboss/mojarra/pull/26, https://github.com/wildfly/wildfly/pull/12062 (was: https://github.com/jboss/mojarra/pull/26)
> JSF ViewMap Regression
> ----------------------
>
> Key: WFLY-11275
> URL: https://issues.jboss.org/browse/WFLY-11275
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.1.Final, 15.0.0.Final, 15.0.1.Final
> Environment: Java 8
> Wildfly 14.0.1
> Reporter: Cody Lerum
> Assignee: Dmitrii Tikhomirov
> Priority: Major
>
> I'm been running into an occasional NPE in production with JSF after migrating from Wildfly 11 to Wildfly 14.0.1 ( Mojarra 2.2.13.SP4 -> 2.3.5.SP2 ) and I believe I've tracked down a small demo project that duplicates the issue. I've set the project to JSF 2.2 so it will deploy on both WF 11 and WF 14.
> The basic problem is that when two pages with the same view id are loaded in separate tabs. From there is one of the tabs is posted and the result navigates to a different view id all references to that view id are removed from the view map. If the post does not navigate to a different view id then all works normally.
> My assumption is that when the post navigates away to a new view id any reference to any page with the same view id is removed from the view map. This did not occur in Wildfly 11.
> Additional clue is that even though the viewmap reference is removed the view scoped beans referencing it are not destroyed.
> Demo project at https://github.com/codylerum/demos/tree/ee7/jsf-npe
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months