[JBoss JIRA] (WFLY-5439) Data Race accessing org/jboss/dmr/ModelNode.value
by Thomas Krieger (JIRA)
Thomas Krieger created WFLY-5439:
------------------------------------
Summary: Data Race accessing org/jboss/dmr/ModelNode.value
Key: WFLY-5439
URL: https://issues.jboss.org/browse/WFLY-5439
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 10.0.0.Beta1
Environment: jdk 1.8 64 bit
windows
Reporter: Thomas Krieger
Assignee: Jason Greene
Priority: Minor
Data Race while accessing org/jboss/dmr/ModelNode.value during startup of jboss:
Two Threads are accessing this field without synchronization:
Stacktrace for Thread writing field:
org/jboss/threads/JBossThread.run
java/util/concurrent/ThreadPoolExecutor$Worker.run
java/util/concurrent/ThreadPoolExecutor.runWorker
org/jboss/as/controller/ParallelBootOperationStepHandler$ParallelBootTask.run
org/jboss/as/controller/AbstractOperationContext.executeOperation
org/jboss/as/controller/AbstractOperationContext.processStages
org/jboss/as/controller/AbstractOperationContext.executeStep
org/jboss/as/controller/AbstractAddStepHandler.execute
org/jboss/as/controller/AbstractAddStepHandler.populateModel
org/jboss/as/controller/AbstractAddStepHandler.populateModel
org/jboss/as/jsf/subsystem/JSFSubsystemAdd.populateModel
org/jboss/as/controller/AttributeDefinition.validateAndSet
org/jboss/dmr/ModelNode.get
Stacktrace for reading Field:
org/jboss/as/controller/AbstractControllerService$1.run
org/jboss/as/server/ServerService.boot
org/jboss/as/server/ServerService.boot
org/jboss/as/controller/AbstractControllerService.boot
org/jboss/as/controller/AbstractControllerService.boot
org/jboss/as/controller/ModelControllerImpl.boot
org/jboss/as/controller/OperationContextImpl.executeOperation
org/jboss/as/controller/AbstractOperationContext.executeOperation
org/jboss/as/controller/AbstractOperationContext.processStages
org/jboss/as/controller/AbstractOperationContext.executeDoneStage
org/jboss/as/controller/OperationContextImpl.createPersistenceResource
org/jboss/as/controller/ModelControllerImpl.writeModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/as/controller/registry/Resource$Tools.readModel
org/jboss/dmr/ModelNode.clone
Found by
[link vmlens|http://vmlens.com]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice causes JVM crash
by Davide Marchetti (JIRA)
[ https://issues.jboss.org/browse/WFLY-5432?page=com.atlassian.jira.plugin.... ]
Davide Marchetti commented on WFLY-5432:
----------------------------------------
Hi Alessio,
I believe you. I still do not understand why I have this problem, but I'm starting to think it must be some subtle HARDWARE-related issue.
In my tests, the only "constant" is that the tested jdk versions, the wildflys, the other Centos machine... everything was running on my developer machine.
Therefore, if everything is different but the hardware is the same, it must be that... figuring out what is causing this problem is however very difficult.
>From my point of view you can therefore close the issue as cannot reproduce.
Thank you anyway.
> Wildfly SOAP webservice causes JVM crash
> ----------------------------------------
>
> Key: WFLY-5432
> URL: https://issues.jboss.org/browse/WFLY-5432
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.1.Final, 10.0.0.CR2
> Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
> Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
> Reporter: Davide Marchetti
> Assignee: Alessio Soldano
> Priority: Blocker
> Labels: crash, jvm, soap, webservice
> Attachments: SOAPTest.war
>
>
> The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
> The error printed is:
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
> #
> # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
> # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # J org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
>
> #
> # If you would like to submit a bug report, please include
> # instructions on how to reproduce the bug and visit:
> # 15:56:03,314 INFO [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
> http://icedtea.classpath.org/bugzilla
> #
> The webservice does nothing, just a System.out.print("xxxxx").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-302) Add SHA-512-256 to list of algorithms for digest passwords and SASL digest
by David Lloyd (JIRA)
David Lloyd created ELY-302:
-------------------------------
Summary: Add SHA-512-256 to list of algorithms for digest passwords and SASL digest
Key: ELY-302
URL: https://issues.jboss.org/browse/ELY-302
Project: WildFly Elytron
Issue Type: Enhancement
Components: Passwords, SASL
Reporter: David Lloyd
[RFC 7616|http://www.rfc-editor.org/rfc/rfc7616.txt] was released, indicating that SHA-512-256 is a supported algorithm for digest HTTP mechanisms. We need support for that algorithm as a password. We also then should add a corresponding SASL variant to the DIGEST suite.
There is no MessageDigest for SHA-512-256. This can be accomplished by truncating the output of SHA-512 to 256 bits (32 bytes). A wrapper MessageDigest could be created, or the ability to arbitrarily truncate the digest could be added to the DIGEST mechanism.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice causes JVM crash
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-5432?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-5432:
---------------------------------------
I've tried but could not reproduce this issue (I'm on fedora, oracle jdk 1.8.0_40). I had to modify SubmitOrder in your war as the reference to the wsdl was broken (the war as is fails deployment on WildFly), used a simple @WebService annotation in it, hence full code-first-approach.
Then I deployed the modified war on a vanilla WildFly 9.0.1.Final (didn't change anything in the configuration) and started the container.
I downloaded SOAPUI 5.2.0 and created a test project using the wsdl of the deployed application. Then I modified the request message to have valid data (no "?") and started the load test with 10 threads, 1ms delay, 1200 sec limit.
I've got 1.680.520 successful invocations (no error/failure) with an average of ~1400 tps (clearly, I could have had far better results by tuning logging, etc....)
To be honest, as part of our perf tests, we've gone way further than the numbers reported in this jira.
So, unless you can provide a way for reproducing, I'm not sure how to help here and would likely close this jira as cannot reproduce, sorry.
> Wildfly SOAP webservice causes JVM crash
> ----------------------------------------
>
> Key: WFLY-5432
> URL: https://issues.jboss.org/browse/WFLY-5432
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.1.Final, 10.0.0.CR2
> Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
> Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
> Reporter: Davide Marchetti
> Assignee: Alessio Soldano
> Priority: Blocker
> Labels: crash, jvm, soap, webservice
> Attachments: SOAPTest.war
>
>
> The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
> The error printed is:
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
> #
> # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
> # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # J org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
>
> #
> # If you would like to submit a bug report, please include
> # instructions on how to reproduce the bug and visit:
> # 15:56:03,314 INFO [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
> http://icedtea.classpath.org/bugzilla
> #
> The webservice does nothing, just a System.out.print("xxxxx").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5438) JUnit version mismatch
by Josef Cacek (JIRA)
Josef Cacek created WFLY-5438:
---------------------------------
Summary: JUnit version mismatch
Key: WFLY-5438
URL: https://issues.jboss.org/browse/WFLY-5438
Project: WildFly
Issue Type: Bug
Components: Build System
Reporter: Josef Cacek
Assignee: Paul Gier
Priority: Critical
JUnit dependency defined in WildFly Core is {{4.11}}, but current WildFly-Arquillian version depends on version {{4.12}}. It can lead to API incompatibilities and also project compilation problems (as was for instance in the [PR 8200|https://github.com/wildfly/wildfly/pull/8200#issuecomment-143217516])
>From my PoV is the best solution upgrade JUnit version in WF-CORE or exclude the junit:junit from the wildfly-core dependency.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5437) Stale data after cluster wide rebalance with remote EJB invocations
by Richard Janík (JIRA)
Richard Janík created WFLY-5437:
-----------------------------------
Summary: Stale data after cluster wide rebalance with remote EJB invocations
Key: WFLY-5437
URL: https://issues.jboss.org/browse/WFLY-5437
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Richard Janík
Assignee: Paul Ferraro
Hi,
we're occasionally getting stale data on remote EJB invocations (number counter returns number 1 lower than expected, see example). This is usually preceded (~6 seconds before that) by cluster wide rebalance after a node is brought back from dead.
- 2000 clients, stale data is uncommon
- requests from a single client are separated by a 4 second window.
An example of stale data:
{code}
2015/08/28 12:45:11:868 EDT [WARN ][Runner - 553] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Response serial does not match. Expected: 87, received: 86, runner: 553.>
{code}
Server side log excerpt about rebalance:
{code}
[JBossINF] [0m[0m12:45:02,780 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf21) ISPN000094: Received new cluster view for channel web: [perf21|7] (4) [perf21, perf20, perf18, perf19]
[JBossINF] [0m[0m12:45:02,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf21) ISPN000094: Received new cluster view for channel ejb: [perf21|7] (4) [perf21, perf20, perf18, perf19]
[JBossINF] [0m[0m12:45:03,660 INFO [org.infinispan.CLUSTER] (remote-thread--p3-t6) ISPN000310: Starting cluster-wide rebalance for cache repl, topology CacheTopology{id=12, rebalanceId=5, currentCH=ReplicatedConsistentHash{ns = 60, owners = (3)[perf21: 20, perf20: 20, perf18: 20]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (4)[perf21: 15, perf20: 15, perf18: 15, perf19: 15]}, unionCH=null, actualMembers=[perf21, perf20, perf18, perf19]}
[JBossINF] [0m[0m12:45:03,660 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t16) ISPN000310: Starting cluster-wide rebalance for cache dist, topology CacheTopology{id=16, rebalanceId=7, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf21: 27+26, perf20: 26+28, perf18: 27+26]}, pendingCH=DefaultConsistentHash{ns=80, owners = (4)[perf21: 20+20, perf20: 20+20, perf18: 20+20, perf19: 20+20]}, unionCH=null, actualMembers=[perf21, perf20, perf18, perf19]}
[JBossINF] [0m[0m12:45:03,663 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t19) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-default.war, topology CacheTopology{id=16, rebalanceId=7, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf21: 27+26, perf20: 26+28, perf18: 27+26]}, pendingCH=DefaultConsistentHash{ns=80, owners = (4)[perf21: 20+20, perf20: 20+20, perf18: 20+20, perf19: 20+20]}, unionCH=null, actualMembers=[perf21, perf20, perf18, perf19]}
[JBossINF] [0m[0m12:45:03,664 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t18) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war, topology CacheTopology{id=16, rebalanceId=7, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf21: 27+26, perf20: 26+28, perf18: 27+26]}, pendingCH=DefaultConsistentHash{ns=80, owners = (4)[perf21: 20+20, perf20: 20+20, perf18: 20+20, perf19: 20+20]}, unionCH=null, actualMembers=[perf21, perf20, perf18, perf19]}
[JBossINF] [0m[0m12:45:03,759 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t18) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war, topology id = 16
[JBossINF] [0m[0m12:45:03,820 INFO [org.infinispan.CLUSTER] (remote-thread--p3-t7) ISPN000336: Finished cluster-wide rebalance for cache repl, topology id = 12
[JBossINF] [0m[0m12:45:03,832 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t18) ISPN000336: Finished cluster-wide rebalance for cache dist, topology id = 16
[JBossINF] [0m[0m12:45:03,958 INFO [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology CacheTopology{id=12, rebalanceId=5, currentCH=ReplicatedConsistentHash{ns = 60, owners = (3)[perf21: 20, perf20: 20, perf18: 20]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (4)[perf21: 15, perf20: 15, perf18: 15, perf19: 15]}, unionCH=null, actualMembers=[perf21, perf20, perf18, perf19]}
[JBossINF] [0m[0m12:45:04,760 INFO [org.infinispan.CLUSTER] (remote-thread--p4-t18) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-default.war, topology id = 16
[JBossINF] [0m[0m12:45:06,331 INFO [org.infinispan.CLUSTER] (remote-thread--p3-t9) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology id = 12
{code}
And a link to our jobs if you're interested:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...
This behavior has been observed with jvmkill and undeploy scenario, on REPL-SYNC, REPL-ASYNC and DIST-SYNC caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months