March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9954) Too many services and dependencies created for EJBs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9954?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-9954: ------------------------------ Summary: Too many services and dependencies created for EJBs (was: Too many services created for EJBs) > Too many services and dependencies created for EJBs > --------------------------------------------------- > > Key: WFLY-9954 > URL: https://issues.jboss.org/browse/WFLY-9954 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Priority: Critical > > If a deployment contains more than 2730 EJBs, the deployment's INSTALL phase will get a stack trace like this: > {noformat} > 2018-03-25 08:22:34,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."example.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "example.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Too many dependencies specified (max is 16383) .......... (*1) > at org.jboss.msc.service.ServiceBuilderImpl.doAddDependency(ServiceBuilderImpl.java:216) > at org.jboss.msc.service.ServiceBuilderImpl.addDependenciesNoCheck(ServiceBuilderImpl.java:158) > at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:152) > at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:142) > at org.jboss.as.naming.deployment.JndiNamingDependencyProcessor.deploy(JndiNamingDependencyProcessor.java:59) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) > ... 5 more > {noformat} > The reason is that the INSTALL phase has six additional dependencies per EJB: > * service jboss.naming.context.java.comp.example.example.<class-name>.InAppClientContainer > * service jboss.naming.context.java.comp.example.example.<class-name>.InstanceName > * service jboss.deployment.unit."example.jar".component.<class-name>.JndiBindingsService > * service jboss.naming.context.java.comp.example.example.<class-name>.UserTransaction > * service jboss.naming.context.java.comp.example.example.<class-name>.TransactionSynchronizationRegistry > * service jboss.naming.context.java.comp.example.example.<class-name>.BeanManager > We probably should not be creating N dependencies per deployment object since all the services of a given kind are always started together. They could be grouped at a deployment level instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2361) Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle

by Sidi Mohamed EL AATIFI (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2361?page=com.atlassian.jira.plugi... ] Sidi Mohamed EL AATIFI updated DROOLS-2361: ------------------------------------------- Attachment: before.png > Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle > -------------------------------------------------------------------------- > > Key: DROOLS-2361 > URL: https://issues.jboss.org/browse/DROOLS-2361 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.6.0.Final > Reporter: Sidi Mohamed EL AATIFI > Assignee: Mario Fusco > Labels: performance > Attachments: before.png > > > This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9 > It's not a bug in Drools but will be affected severely if using Drools for serious workloads. > in my case 40% of CPU usage was to > _java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode > !before.png|thumbnail! > UPDATE: > One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts. > and provide identityHashCode backed by native (fast) hashCode -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2361) Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle

by Sidi Mohamed EL AATIFI (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2361?page=com.atlassian.jira.plugi... ] Sidi Mohamed EL AATIFI updated DROOLS-2361: ------------------------------------------- Description: This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9 It's not a bug in Drools but will be affected severely if using Drools for serious workloads. in my case 40% of CPU usage was to _java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode !before.png|thumbnail! UPDATE: One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts. and provide identityHashCode backed by native (fast) hashCode was: This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9 It's not a bug in Drools but will be affected severely if using Drools for serious workloads. in my case 40% of CPU usage was to _java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode UPDATE: One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts. and provide identityHashCode backed by native (fast) hashCode > Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle > -------------------------------------------------------------------------- > > Key: DROOLS-2361 > URL: https://issues.jboss.org/browse/DROOLS-2361 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.6.0.Final > Reporter: Sidi Mohamed EL AATIFI > Assignee: Mario Fusco > Labels: performance > Attachments: before.png > > > This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9 > It's not a bug in Drools but will be affected severely if using Drools for serious workloads. > in my case 40% of CPU usage was to > _java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode > !before.png|thumbnail! > UPDATE: > One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts. > and provide identityHashCode backed by native (fast) hashCode -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1537) PolicyContext.getContext("javax.security.auth.Subject.container")

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1537?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev commented on ELY-1537: ------------------------------------ Forum discussion: https://developer.jboss.org/thread/277260 [~mchoma] provided a workaround. According to [~dehort] which is working on the customer case, the problem with that workaround is that you are likely exposing a private Elytron API which may change. > PolicyContext.getContext("javax.security.auth.Subject.container") > ----------------------------------------------------------------- > > Key: ELY-1537 > URL: https://issues.jboss.org/browse/ELY-1537 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.2.3.Final > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > > PolicyContext.getContext("javax.security.auth.Subject.container") returns null when using elytron to protect a web application. > This should return the authenticated subject. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1537) PolicyContext.getContext("javax.security.auth.Subject.container")

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1537?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev moved JBEAP-14325 to ELY-1537: -------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1537 (was: JBEAP-14325) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) Affects Version/s: 1.2.3.Final (was: 7.1.0.GA) > PolicyContext.getContext("javax.security.auth.Subject.container") > ----------------------------------------------------------------- > > Key: ELY-1537 > URL: https://issues.jboss.org/browse/ELY-1537 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.2.3.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > > PolicyContext.getContext("javax.security.auth.Subject.container") returns null when using elytron to protect a web application. > This should return the authenticated subject. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1537) PolicyContext.getContext("javax.security.auth.Subject.container")

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1537?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev reassigned ELY-1537: ---------------------------------- Assignee: Darran Lofthouse (was: Ilia Vassilev) > PolicyContext.getContext("javax.security.auth.Subject.container") > ----------------------------------------------------------------- > > Key: ELY-1537 > URL: https://issues.jboss.org/browse/ELY-1537 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.2.3.Final > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > > PolicyContext.getContext("javax.security.auth.Subject.container") returns null when using elytron to protect a web application. > This should return the authenticated subject. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9956) [GSS](7.1.z) Stack trace of a primary request of Infinispan is lost, damaging supportability severely

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9956?page=com.atlassian.jira.plugin.... ] Yeray Borges moved JBEAP-14324 to WFLY-9956: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9956 (was: JBEAP-14324) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 12.0.0.Final (was: 7.1.0.GA) Fix Version/s: (was: 7.1.2.GA) > [GSS](7.1.z) Stack trace of a primary request of Infinispan is lost, damaging supportability severely > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-9956 > URL: https://issues.jboss.org/browse/WFLY-9956 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final > Reporter: Yeray Borges > Assignee: Yeray Borges > Labels: top-50-list > > A request is handled by XNIO's "default task-NNN" thread. If the request executes a clustering cache operation, like session replication, it waits for the backup operation on another server. And if the other server failed on the backup operation, the primary server unwraps the exception to print only the remote exception. The original context of thread "default task-NNN" is lost and a user can't even identify what the primary operation was. > This affects supportability too much. It seems only JDG 7.1 is free from this issue (it has {{AsyncInterceptorChain}}). All other releases like EAP 7.1, RHSSO which is based on EAP 7.0 has this issue. > See the "Forum Reference" link of a mail thread for the detail. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9956) Stack trace of a primary request of Infinispan is lost, damaging supportability severely

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9956?page=com.atlassian.jira.plugin.... ] Yeray Borges updated WFLY-9956: ------------------------------- Summary: Stack trace of a primary request of Infinispan is lost, damaging supportability severely (was: [GSS](7.1.z) Stack trace of a primary request of Infinispan is lost, damaging supportability severely) > Stack trace of a primary request of Infinispan is lost, damaging supportability severely > ---------------------------------------------------------------------------------------- > > Key: WFLY-9956 > URL: https://issues.jboss.org/browse/WFLY-9956 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final > Reporter: Yeray Borges > Assignee: Yeray Borges > Labels: top-50-list > > A request is handled by XNIO's "default task-NNN" thread. If the request executes a clustering cache operation, like session replication, it waits for the backup operation on another server. And if the other server failed on the backup operation, the primary server unwraps the exception to print only the remote exception. The original context of thread "default task-NNN" is lost and a user can't even identify what the primary operation was. > This affects supportability too much. It seems only JDG 7.1 is free from this issue (it has {{AsyncInterceptorChain}}). All other releases like EAP 7.1, RHSSO which is based on EAP 7.0 has this issue. > See the "Forum Reference" link of a mail thread for the detail. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1536) DigestSaslClient parse but ignore "stale" param

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1536?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1536: ---------------------------- Description: Server sends "stale=true" when invalid nonce is used. Client should repeat authentication with new nonce, but it ignores it instead. rfc2831: {panel} If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication. {panel} was: Server sends "stale=true" when invalid nonce is used. Client should repeat authentication with new nonce, but it ignores it instead. > DigestSaslClient parse but ignore "stale" param > ----------------------------------------------- > > Key: ELY-1536 > URL: https://issues.jboss.org/browse/ELY-1536 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.2.3.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > > Server sends "stale=true" when invalid nonce is used. > Client should repeat authentication with new nonce, but it ignores it instead. > rfc2831: > {panel} > If the response is valid, the server MAY choose to deem that > authentication has succeeded. However, if it has been too long since > the previous authentication, or for any other reason, the server MAY > send a new "digest-challenge" with a new value for nonce. The > challenge MAY contain a "stale" directive with value "true", which > says that the client may respond to the challenge using the password > it used in the previous response; otherwise, the client must solicit > the password anew from the user. This permits the server to make sure > that the user has presented their password recently. (The directive > name refers to the previous nonce being stale, not to the last use of > the password.) Except for the handling of "stale", after sending the > "digest-challenge" authentication proceeds as in the case of initial > authentication. > {panel} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2349) [DMN Editor] Decision Navigator dock

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2349?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-2349: ------------------------------------- [~karreiro] According to today's meeting, am I right that this Jira solves just first three points from description? > [DMN Editor] Decision Navigator dock > ------------------------------------ > > Key: DROOLS-2349 > URL: https://issues.jboss.org/browse/DROOLS-2349 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Attachments: prototype.png > > > The "Decision Navigator" is docked next to the Project Explorer. See: > !prototype.png|thumbnail! > - Tree navigation offers a view of the entire DRG. Diagram nodes are represented within the tree. > - User defined DRD’s are represented as top level tree nodes, with supporting decision and input data represented as subordinate tree nodes. > - Tree structure only goes as deep as primary logic definition, such as a decision table (nested logic is not represented in the tree.) > - The Navigator includes a preview image which represents a thumbnail view of the diagram view selected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2018