[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2327:
--------------------------------
Yes. This is not a showstopper, as retransmission for leave requests is unicast and therefore ~500ms (default).
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.17
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> h4. Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[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)
7 years, 5 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)
7 years, 5 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)
7 years, 5 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)
7 years, 5 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)
7 years, 5 months