[JBoss JIRA] (JGRP-2287) Thread safety issues and race conditions in VERIFY_SUSPECT
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2287?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2287 at 1/9/19 3:03 AM:
--------------------------------------------------------
Re 1: {{DelayQueue}} is synchronized, so why should this be a problem?
Re 2: {{timer}} was set to {{volatile}} by a PR
was (Author: belaban):
Re 1: {{DelayQueue}} is synchronized, so why should this be a problem?
> Thread safety issues and race conditions in VERIFY_SUSPECT
> ----------------------------------------------------------
>
> Key: JGRP-2287
> URL: https://issues.jboss.org/browse/JGRP-2287
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.16
>
>
> While addressing JGRP-2286, I noticed a number of thread safety issues and race conditions in VERIFY_SUSPECT, e.g.
> 1. "suspects" DelayQueue is accessed concurrently within synchronized block by most of the code, however, the run() method calls isEmpty(), size(), and most notably, drainTo(...) without sufficient exclusivity. drainTo is particularly problematic in the case of concurrent modifications.
> 2. "timer" Thread is non-volatile, but its reference is set by multiple threads.
> 3. The startTimer() method only creates a new thread if Thread.isAlive() returns false. However, if the thread is just completing (i.e. exiting its loop), this method can return true, and the verification of suspected members can be delayed until the next suspect event.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (JGRP-2287) Thread safety issues and race conditions in VERIFY_SUSPECT
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2287?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2287:
--------------------------------
Re 1: {{DelayQueue}} is synchronized, so why should this be a problem?
> Thread safety issues and race conditions in VERIFY_SUSPECT
> ----------------------------------------------------------
>
> Key: JGRP-2287
> URL: https://issues.jboss.org/browse/JGRP-2287
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.16
>
>
> While addressing JGRP-2286, I noticed a number of thread safety issues and race conditions in VERIFY_SUSPECT, e.g.
> 1. "suspects" DelayQueue is accessed concurrently within synchronized block by most of the code, however, the run() method calls isEmpty(), size(), and most notably, drainTo(...) without sufficient exclusivity. drainTo is particularly problematic in the case of concurrent modifications.
> 2. "timer" Thread is non-volatile, but its reference is set by multiple threads.
> 3. The startTimer() method only creates a new thread if Thread.isAlive() returns false. However, if the thread is just completing (i.e. exiting its loop), this method can return true, and the verification of suspected members can be delayed until the next suspect event.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 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:
------------------------------------
I had already tried that, but I get a deployment error when I try to deploy my war file in WildFly 15.0.0 Final.
Please find the error below:
13:08:38,196 INFO [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 76) HHH000206: hibernate.properties not found
13:08:38,425 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 77) WFLYCLINF0002: Started client-mappings cache from ejb container
13:08:39,790 INFO [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 76) HCANN000001: Hibernate Commons Annotations {5.0.4.Final}
13:08:40,381 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 76) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
13:08:40,447 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 76) HHH000431: Unable to determine H2 database version, certain features may not work
13:08:40,625 INFO [org.hibernate.envers.boot.internal.EnversServiceImpl] (ServerService Thread Pool -- 76) Envers integration enabled? : true
13:08:41,742 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 76) MSC000001: Failed to start service jboss.persistenceunit."VHQRest-3.11.27.06.war#dbPersistence": org.jboss.msc.service
.StartException in service jboss.persistenceunit."VHQRest-3.11.27.06.war#dbPersistence": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:198)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:128)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:649)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:212)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:92)
at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:483)
at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:116)
at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:101)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:297)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:904)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:935)
at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:141)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:67)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:356)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$1300(PersistenceUnitServiceImpl.java:71)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:190)
... 9 more
I already tried adding jboss-deployment-structure.xml in the path
..\wildfly-15.0.0.Final\modules\system\layers\base\org\jboss\as\product\wildfly-full\dir\META-INF, but it did not help.
Then I stopped my process of deployment in WildFly 15 final as I thought, I am deviating from the actual issue which I am facing.
Let me know if you need any other information.
> 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: Jason Greene
> Priority: Major
>
> 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, 9 months
[JBoss JIRA] (JGRP-2287) Thread safety issues and race conditions in VERIFY_SUSPECT
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2287?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2287:
---------------------------
Fix Version/s: 4.0.16
> Thread safety issues and race conditions in VERIFY_SUSPECT
> ----------------------------------------------------------
>
> Key: JGRP-2287
> URL: https://issues.jboss.org/browse/JGRP-2287
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.16
>
>
> While addressing JGRP-2286, I noticed a number of thread safety issues and race conditions in VERIFY_SUSPECT, e.g.
> 1. "suspects" DelayQueue is accessed concurrently within synchronized block by most of the code, however, the run() method calls isEmpty(), size(), and most notably, drainTo(...) without sufficient exclusivity. drainTo is particularly problematic in the case of concurrent modifications.
> 2. "timer" Thread is non-volatile, but its reference is set by multiple threads.
> 3. The startTimer() method only creates a new thread if Thread.isAlive() returns false. However, if the thread is just completing (i.e. exiting its loop), this method can return true, and the verification of suspected members can be delayed until the next suspect event.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (WFCORE-4266) Classes for newer versions are not loaded from Multi-Release-JARs in WARs
by Daniel Schwering (Jira)
[ https://issues.jboss.org/browse/WFCORE-4266?page=com.atlassian.jira.plugi... ]
Daniel Schwering commented on WFCORE-4266:
------------------------------------------
Thank you for looking into this. I added some comments to your commit. When I manually set the version to 11 in the debugger, the correct file is loaded from the MR Jar
> Classes for newer versions are not loaded from Multi-Release-JARs in WARs
> -------------------------------------------------------------------------
>
> Key: WFCORE-4266
> URL: https://issues.jboss.org/browse/WFCORE-4266
> Project: WildFly Core
> Issue Type: Bug
> Components: VFS
> Environment: Java 9+
> Reporter: Daniel Schwering
> Priority: Major
> Attachments: buggywar.src.zip, buggywar.war, multireleaselib-0.0.1-SNAPSHOT.jar, multireleaselib-0.0.1-SNAPSHOT.jar, multireleaselib.src.zip, multireleaselib.src.zip
>
>
> 1
> down vote
> favorite
> Since Java 9 there are Multi-Release JARs ([MRJARS|https://openjdk.java.net/jeps/238]) that allow different classes for different Java versions to be included in one JAR file. I was surprised when a Wildfly 14 running on Java 11 executed Java-8-code in a JAR included in a WAR although the JAR was a MRJAR with code for Java 11. That JAR included as a dependency for a regular Java SE project is running different code depending on the running JRE, but when included in a WAR, the Java-11-code seems to be ignored.
> Is that expected behavior for a webserver, as Java EE 8 does not explicitly require Java 9 (which introduced MRJARs) but only Java 8?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (DROOLS-3474) Create HTML and CSS for List/Map data objects
by tao zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3474?page=com.atlassian.jira.plugi... ]
tao zhu edited comment on DROOLS-3474 at 1/9/19 2:02 AM:
---------------------------------------------------------
[~aglass] #7 icon to remain visible is make sense to me.Thank you.
[~srambach] Thanks for your updates. There are 3 very small problems.
!Rectangle2.png|thumbnail!
1. A small problem of modal padding.There are space between the line and grey background.
2. The dangling vertical line is a little strange. There is a horizontal line on the top of modal footer. Could you help me add a horizontal line?
3. The button of “+ Add phones” should left align with the title of “Phones”
was (Author: zhutaojiajia):
[~aglass] #7 icon to remain visible is make sense to me.Thank you.
[~srambach] Thanks for your updates. There are 3 very small problems.
!Rectangle.png|thumbnail!
1. A small problem of modal padding.There are space between the line and grey background.
2. The dangling vertical line is a little strange. There is a horizontal line on the top of modal footer. Could you help me add a horizontal line?
3. The button of “+ Add phones” should left align with the title of “Phones”
> Create HTML and CSS for List/Map data objects
> ---------------------------------------------
>
> Key: DROOLS-3474
> URL: https://issues.jboss.org/browse/DROOLS-3474
> Project: Drools
> Issue Type: Story
> Components: Scenario Simulation and Testing
> Reporter: Amy Glass
> Assignee: Sarah Rambacher
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Rectangle.png, Rectangle2.png, firefox.png
>
>
> Provide HTML and CSS for the designs in Drools-3098.
> Will first provide HTML structure, and follow up with CSS styling.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months