[JBoss JIRA] (WFLY-9169) Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
by blass megod (JIRA)
[ https://issues.jboss.org/browse/WFLY-9169?page=com.atlassian.jira.plugin.... ]
blass megod updated WFLY-9169:
------------------------------
Issue Type: Bug (was: Feature Request)
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
> --------------------------------------------------------------------------
>
> Key: WFLY-9169
> URL: https://issues.jboss.org/browse/WFLY-9169
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> AIX Version 7.2
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pap6480sr3fp22-20161213_02(SR3 FP22))
> IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20161209_329148 (JIT enabled, AOT enabled)
> J9VM - R28_20161209_1345_B329148
> JIT - tr.r14.java.green_20161207_128946
> GC - R28_20161209_1345_B329148_CMPRSS
> J9CL - 20161209_329148)
> JCL - 20161213_01 based on Oracle jdk8u111-b14
> Reporter: blass megod
> Assignee: David Lloyd
>
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE):
> {code}
> 3XMTHREADINFO "p0" J9VMThread:0x00000000304BD100, j9thread_t:0x0000010029E423D0, java/lang/Thread:0x0000000408F664F8, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x8C96, isDaemon:false)
> 3XMTHREADINFO1 (native thread ID:0x20401E7, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000101)
> 3XMCPUTIME CPU usage total: 0.379679000 secs, user: 0.354485000 secs, system: 0.025194000 secs, current category="Application"
> 3XMTHREADBLOCK Waiting on: java/lang/Object@0x000000040ECC59A0 Owned by: <unowned>
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/lang/Object.wait(Native Method)
> 4XESTACKTRACE at java/lang/Object.wait(Object.java:172(Compiled Code))
> 4XESTACKTRACE at org/jboss/remoting3/spi/AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190(Compiled Code))
> 5XESTACKTRACE (entered lock: java/lang/Object@0x000000040ECC59A0, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache.release(EndpointCache.java:67(Compiled Code))
> 5XESTACKTRACE (entered lock: org/jboss/naming/remote/client/EndpointCache@0x00000004002F3830, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache$EndpointWrapper.close(EndpointCache.java:183(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/InitialContextFactory$1.close(InitialContextFactory.java:233(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/RemoteContext.close(RemoteContext.java:290(Compiled Code))
> 4XESTACKTRACE at javax/naming/InitialContext.close(InitialContext.java:567(Compiled Code))
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9169) Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
by blass megod (JIRA)
blass megod created WFLY-9169:
---------------------------------
Summary: Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
Key: WFLY-9169
URL: https://issues.jboss.org/browse/WFLY-9169
Project: WildFly
Issue Type: Feature Request
Components: Remoting
Affects Versions: 10.1.0.Final
Environment: WildFly 10.1.0.Final
AIX Version 7.2
java version "1.8.0"
Java(TM) SE Runtime Environment (build pap6480sr3fp22-20161213_02(SR3 FP22))
IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20161209_329148 (JIT enabled, AOT enabled)
J9VM - R28_20161209_1345_B329148
JIT - tr.r14.java.green_20161207_128946
GC - R28_20161209_1345_B329148_CMPRSS
J9CL - 20161209_329148)
JCL - 20161213_01 based on Oracle jdk8u111-b14
Reporter: blass megod
Assignee: David Lloyd
Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE):
{code}
3XMTHREADINFO "p0" J9VMThread:0x00000000304BD100, j9thread_t:0x0000010029E423D0, java/lang/Thread:0x0000000408F664F8, state:CW, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0x8C96, isDaemon:false)
3XMTHREADINFO1 (native thread ID:0x20401E7, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000101)
3XMCPUTIME CPU usage total: 0.379679000 secs, user: 0.354485000 secs, system: 0.025194000 secs, current category="Application"
3XMTHREADBLOCK Waiting on: java/lang/Object@0x000000040ECC59A0 Owned by: <unowned>
3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at java/lang/Object.wait(Native Method)
4XESTACKTRACE at java/lang/Object.wait(Object.java:172(Compiled Code))
4XESTACKTRACE at org/jboss/remoting3/spi/AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190(Compiled Code))
5XESTACKTRACE (entered lock: java/lang/Object@0x000000040ECC59A0, entry count: 1)
4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache.release(EndpointCache.java:67(Compiled Code))
5XESTACKTRACE (entered lock: org/jboss/naming/remote/client/EndpointCache@0x00000004002F3830, entry count: 1)
4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache$EndpointWrapper.close(EndpointCache.java:183(Compiled Code))
4XESTACKTRACE at org/jboss/naming/remote/client/InitialContextFactory$1.close(InitialContextFactory.java:233(Compiled Code))
4XESTACKTRACE at org/jboss/naming/remote/client/RemoteContext.close(RemoteContext.java:290(Compiled Code))
4XESTACKTRACE at javax/naming/InitialContext.close(InitialContext.java:567(Compiled Code))
...
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9168) Log error org.jboss.security.annotation.SecurityDomain annotation is used in EJB
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-9168?page=com.atlassian.jira.plugin.... ]
Lin Gao moved JBEAP-12512 to WFLY-9168:
---------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9168 (was: JBEAP-12512)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Security
(was: EJB)
(was: Security)
Affects Version/s: (was: 7.1.0.ER3)
> Log error org.jboss.security.annotation.SecurityDomain annotation is used in EJB
> --------------------------------------------------------------------------------
>
> Key: WFLY-9168
> URL: https://issues.jboss.org/browse/WFLY-9168
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> The annotation *{{org.jboss.security.annotation.SecurityDomain}}* is present in the legacy security packages and documented in 7.1 [Javadoc|https://access.redhat.com/webassets/avalon/d/red-hat-jboss-enterp...]:
> {quote}
> Annotation for specifying the JBoss security domain for EJBs.
> {quote}
> Nevertheless this annotation doesn't work and the one from another package has to be used instead - {{org.jboss.ejb3.annotation.SecurityDomain}}.
> Server doesn't log an error or warning when the legacy one is used.
> *Suggested fix:*
> Add a deployment processor which will log error when the legacy annotation is used in the deployment.
> Another possibility how to fix this would be to add support for the legacy annotation too.
> I'll create a separate JIRA for JavaDoc update in the legacy annotation class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3139) Optimize ValidateModelStepHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3139:
----------------------------------------
Summary: Optimize ValidateModelStepHandler
Key: WFCORE-3139
URL: https://issues.jboss.org/browse/WFCORE-3139
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.CR1
ValidateModelStepHandler is taking about 100ms during boot. We should optimize this.
Some thoughts:
1) Just add 1 step for it with all needed addresses, rather than 1 step per address.
2) Doing 1) makes it possible to cache looked up resources and MRRs throughout execution so we don't need to do context.readResource[Registration]FromRoot multiple times for the same address.
3) Add a Map<String, AttributeAccess> getAttributeAccesses() to MRR so we can get all of them for an address in one go and avoid having to continually cycle through the MRR tree.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9167) mod_cluster stop status is not updated in balancer/node resource
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9167?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-1141 to WFLY-9167:
------------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-9167 (was: UNDERTOW-1141)
Affects Version/s: (was: 1.4.18.Final)
> mod_cluster stop status is not updated in balancer/node resource
> ----------------------------------------------------------------
>
> Key: WFLY-9167
> URL: https://issues.jboss.org/browse/WFLY-9167
> Project: WildFly
> Issue Type: Bug
> Reporter: Bogdan Sikora
> Assignee: Stuart Douglas
>
> Operation stop on mod_cluster worker disable all contexts (send disable status to balancer) for the duration of session draining. After the session is drained ( successfully or not ), worker stops all contexts ( send stop status to balancer ).
> {noformat}
> [standalone@192.168.122.206:9990 /] /subsystem=modcluster:stop(waittime=-1)
> {
> "outcome" => "success",
> "result" => {"session-draining-complete" => true}
> }
> {noformat}
> However, status stays disabled, but functionallity is of a stopped one
> {noformat}
> "/karel" => {
> "requests" => 0,
> "status" => "disabled"
> }
> {noformat}
> Apache httpd server as balancer correctly recognize stop status and stops contexts
> {noformat}
> /karel, Status: STOPPED Request: 0 Enable Disable
> {noformat}
> *Reproducing:*
> # Set up undertow balancer with one worker
> # Deploy an app to the worker
> # Chech that app is correctly registered with balancer and that is enabled
> # Stop the worker {noformat} /subsystem=modcluster:stop(){noformat}
> # Watch if the context (deployed app) is moved to the stoped status {noformat}/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100){noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1689) maven-checkstyle-plugin does not have a version specified, so the build is non-reproducible
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1689?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet resolved DROOLS-1689.
--------------------------------------
Resolution: Rejected
> maven-checkstyle-plugin does not have a version specified, so the build is non-reproducible
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1689
> URL: https://issues.jboss.org/browse/DROOLS-1689
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Karel Suta
> Priority: Minor
>
> {code}
> $ mvn versions:display-plugin-updates
> ...
> [INFO] ------------------------------------------------------------------------
> [INFO] Building OptaPlanner multiproject parent 8.0.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- versions-maven-plugin:2.1:display-plugin-updates (default-cli) @ optaplanner ---
> [INFO] artifact org.apache.maven.plugins:maven-checkstyle-plugin: checking for updates from central
> [INFO] artifact org.apache.maven.plugins:maven-checkstyle-plugin: checking for updates from jboss-public-repository-group
> [INFO]
> [INFO] All plugins with a version specified are using the latest versions.
> [INFO]
> [WARNING] The following plugins do not have their version specified:
> [WARNING] maven-checkstyle-plugin ..................................... 2.17
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1689) maven-checkstyle-plugin does not have a version specified, so the build is non-reproducible
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1689?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on DROOLS-1689 at 8/2/17 3:36 PM:
------------------------------------------------------------------
Agreed, I see it in jboss-parent on line 276. I also see the version in "mvn help:effective-pom" of optaplanner.
Must be a bug in the versions plugin? It should be reporting it.
was (Author: ge0ffrey):
Agreed, I see it in jboss-parent on line 276. Must be a bug in the versions plugin?
> maven-checkstyle-plugin does not have a version specified, so the build is non-reproducible
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1689
> URL: https://issues.jboss.org/browse/DROOLS-1689
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Karel Suta
> Priority: Minor
>
> {code}
> $ mvn versions:display-plugin-updates
> ...
> [INFO] ------------------------------------------------------------------------
> [INFO] Building OptaPlanner multiproject parent 8.0.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- versions-maven-plugin:2.1:display-plugin-updates (default-cli) @ optaplanner ---
> [INFO] artifact org.apache.maven.plugins:maven-checkstyle-plugin: checking for updates from central
> [INFO] artifact org.apache.maven.plugins:maven-checkstyle-plugin: checking for updates from jboss-public-repository-group
> [INFO]
> [INFO] All plugins with a version specified are using the latest versions.
> [INFO]
> [WARNING] The following plugins do not have their version specified:
> [WARNING] maven-checkstyle-plugin ..................................... 2.17
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months