[JBoss JIRA] (WFWIP-189) Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFWIP-189:
--------------------------------------
Assignee: Jeff Mesnil (was: Brian Stansberry)
> Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-189
> URL: https://issues.jboss.org/browse/WFWIP-189
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blo...] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them).
> The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configm...
> *reproduce*
> * create a config map with ("foo1", "bar1") entry
> * create an operator (size = 1) with a reference to the config map
> * update the config map - add ("foo2", "bar2") entry
> * resize the operator
> *actual*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *expected*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *Environment:*
> *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102...]
> *openshift version:*
> {noformat}
> OpenShift version: 4.1.11
> Kubernetes Master Version: v1.13.4+df9cebc
> {noformat}
> Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here?
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-12486?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-12486:
------------------------------------
[~jmesnil], [~juraci.costa], I've raised priority of this to critical as this seems to be as a regression of WFLY-10991 in some way.
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.jboss.org/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Alexey Usharovski (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Alexey Usharovski edited comment on WFLY-12462 at 9/4/19 10:20 AM:
-------------------------------------------------------------------
You are welcome! Some more comments about how it was. That's kind of study application and at first I use only CDI managed beans for DI and as a next step I tried to replace some Named beans with Stateless EJBs. That was done by replacing annotation and adding Local and Remote interfaces. After that I caught this trouble.
was (Author: usharik):
You are welcome! Some more comments about how it was. That's kind of study application and at first I use only CDI managed beans for DI and as a next step I tried to replace some Named beans with Stateless EJB. That was done by replacing annotation and adding Local and Remote interfaces. After that I caught this trouble.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-12486?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFLY-12486:
-------------------------------
Priority: Critical (was: Major)
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.jboss.org/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Diana Vilkolakova (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Diana Vilkolakova edited comment on WFLY-11604 at 9/4/19 9:46 AM:
------------------------------------------------------------------
{quote}In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'.{quote}
[~dlofthouse] [~fjuma] This holds true for legacy, but when Elytron is enabled the scenario #1 is returning non-anonymous principal. The difference is in [this method|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...]. For elytron the line `elytronDomain.getCurrentSecurityIdentity().getPrincipal();` returns non-anonymous, but legacy returns anonymous. So both scenarios (CallerWithIdentity->BeanWithInjectedPrincipal and also CallerWithIdentity->BeanWithPrincipalFromEJBContext ) are behaving differently than legacy.
was (Author: dvilkola):
{quote}In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'.{quote}
[~dlofthouse] [~fjuma] This holds true for legacy, but when Elytron is enabled the scenario #1 is returning non-anonymous principal. The difference is in [this method|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...]. For elytron `elytronDomain.getCurrentSecurityIdentity().getPrincipal();` returns non-anonymous but legacy returns anonymous.
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Ziakova
> Priority: Critical
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Joerg Baesner (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Joerg Baesner commented on WFLY-12446:
--------------------------------------
[~jaikiran], sure, this is no problem, I have attached the [^server.log.gz]
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: playground-jee8.zip, server.log.gz
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Joerg Baesner (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Joerg Baesner updated WFLY-12446:
---------------------------------
Attachment: server.log.gz
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: playground-jee8.zip, server.log.gz
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Alexey Usharovski (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Alexey Usharovski commented on WFLY-12462:
------------------------------------------
You are welcome! Some more comments about how it was. That's kind of study application and at first I use only CDI managed beans for DI and as a next step I tried to replace some Named beans with Stateless EJB. That was done by replacing annotation and adding Local and Remote interfaces. After that I caught this trouble.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Jaikiran Pai commented on WFLY-12462:
-------------------------------------
Thank you for trying. Having looked at the code, I do believe there's a race condition here. It's now just a matter of narrowing it down to a specific piece of logic. Do report back with details if you find anything new.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Alexey Usharovski (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Alexey Usharovski commented on WFLY-12462:
------------------------------------------
Just tried to reproduce the issue and found that I can't do that now. Going to spend more time with that in closed few days.
Looks like I after some deployments ad redeployments of my app the server came into kind of rare state in which such problem could happens.
Any way I can certify that it persists for several days.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months