September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13866: ------------------------------------------ It seems that smallrye fault tolerance relies now on context propagation for this. Not sure how we can implement that in our integration. > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 21.0.0.Beta1 > > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13871 at 9/15/20 10:57 AM: ---------------------------------------------------------------------- For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available. Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener. This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others. was (Author: rachmato): For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available. Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener. This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others. Then > Re-implement correct suspend/resume behaviour for EJB client > ------------------------------------------------------------ > > Key: WFLY-13871 > URL: https://issues.redhat.com/browse/WFLY-13871 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 21.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 21.0.0.Beta1 > > > When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations. > This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored. > This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13871: -------------------------------------------- For each EJBServerChannel which is created on the server side, there is a separate instance of ClusterTopologyListener and ModuleAvailabilityListener created. In the case of ModuleAvailabilityListener, it provides an API with methods such as moduleAvailable(List<EJBModuleIdentifier> modules) and moduleUnavailable(List<EJBModuleIdentifier> modules) which permit notifying the client on the other end of which modules are or are not available. Due to the way individual EJBServerChannels (which unpack and pack messages) are tied into the single AssociationImpl (which processes unpacked invocations and returns unpacked results), these listeners are defined in the EJBServerChannel and instances of them are registered by the AssociationImpl by methods registerClusterTopologyListener and registerModuleAvailabilityListener. This issue can be solved by creating a third listener, SuspendResumeListener and registering it using a method registerSuspendResumeListener in exactly the same way as the others. Then > Re-implement correct suspend/resume behaviour for EJB client > ------------------------------------------------------------ > > Key: WFLY-13871 > URL: https://issues.redhat.com/browse/WFLY-13871 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 21.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 21.0.0.Beta1 > > > When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations. > This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored. > This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ] Richard Achmatowicz reassigned WFLY-13871: ------------------------------------------ Assignee: Richard Achmatowicz (was: Cheng Fang) > Re-implement correct suspend/resume behaviour for EJB client > ------------------------------------------------------------ > > Key: WFLY-13871 > URL: https://issues.redhat.com/browse/WFLY-13871 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 21.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 21.0.0.Beta1 > > > When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations. > This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored. > This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client

by Richard Achmatowicz (Jira)

Richard Achmatowicz created WFLY-13871: ------------------------------------------ Summary: Re-implement correct suspend/resume behaviour for EJB client Key: WFLY-13871 URL: https://issues.redhat.com/browse/WFLY-13871 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 21.0.0.Beta1 Reporter: Richard Achmatowicz Assignee: Cheng Fang Fix For: 21.0.0.Beta1 When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations. This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored. This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5033) Move org.wildfly.security:wildfly-elytron-jacc into it's own module

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5033?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5033: -------------------------------- Fix Version/s: 13.0.0.Beta7 (was: 13.0.0.Beta6) > Move org.wildfly.security:wildfly-elytron-jacc into it's own module > ------------------------------------------------------------------- > > Key: WFCORE-5033 > URL: https://issues.redhat.com/browse/WFCORE-5033 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta7 > > > Long term it will be desirable for JACC to be within it's own subsystem so it's inclusion can be controlled using layers, however there may be an intermediate step where we split JACC out from the Elytron project so will want to bring it in ideally in it's own module. > The classes within this module have never been public API so we are free to refactor as needed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5336) Editor for client side feel

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5336?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5336: --------------------------------- Description: This is just an editor for testing purposes. > Editor for client side feel > --------------------------- > > Key: DROOLS-5336 > URL: https://issues.redhat.com/browse/DROOLS-5336 > Project: Drools > Issue Type: Feature Request > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > > This is just an editor for testing purposes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5336) Editor for client side feel

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5336?page=com.atlassian.jira.plug... ] Toni Rikkola resolved DROOLS-5336. ---------------------------------- Resolution: Done > Editor for client side feel > --------------------------- > > Key: DROOLS-5336 > URL: https://issues.redhat.com/browse/DROOLS-5336 > Project: Drools > Issue Type: Feature Request > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > > This is just an editor for testing purposes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13870) Upgrade to WildFly Core 13.0.0.Beta6

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13870?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13870: ------------------------------- Description: Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Beta6 Diff to previous integrated release: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta5...13.0.0.Beta6 was: Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Beta5 Diff to previous integrated release: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta4...13.0.0.Beta5 [Release notes|https://issues.redhat.com/secure/ConfigureReport.jspa?versions=1234...] > Upgrade to WildFly Core 13.0.0.Beta6 > ------------------------------------ > > Key: WFLY-13870 > URL: https://issues.redhat.com/browse/WFLY-13870 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: James Perkins > Assignee: Jeff Mesnil > Priority: Major > Fix For: 21.0.0.Beta1 > > > Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Beta6 > Diff to previous integrated release: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta5...13.0.0.Beta6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13870) Upgrade to WildFly Core 13.0.0.Beta6

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13870?page=com.atlassian.jira.plugi... ] Jeff Mesnil reassigned WFLY-13870: ---------------------------------- Assignee: Jeff Mesnil (was: James Perkins) > Upgrade to WildFly Core 13.0.0.Beta6 > ------------------------------------ > > Key: WFLY-13870 > URL: https://issues.redhat.com/browse/WFLY-13870 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: James Perkins > Assignee: Jeff Mesnil > Priority: Major > Fix For: 21.0.0.Beta1 > > > Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Beta5 > Diff to previous integrated release: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta4...13.0.0.Beta5 > [Release notes|https://issues.redhat.com/secure/ConfigureReport.jspa?versions=1234...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 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 September 2020