July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Rhuan Rocha updated WFLY-13638: ------------------------------- Description: In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. was: In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Rhuan Rocha updated WFLY-13638: ------------------------------- Description: In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. was: In the Wildfly 20, if I deploys two application in the same server just one registries an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Rhuan Rocha updated WFLY-13638: ------------------------------- Description: In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. was: In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

Rhuan Rocha created WFLY-13638: ---------------------------------- Summary: Permit multiples applications to the same server registry a MP openapi endpoint Key: WFLY-13638 URL: https://issues.redhat.com/browse/WFLY-13638 Project: WildFly Issue Type: Feature Request Components: MP OpenAPI Affects Versions: 20.0.0.Final Reporter: Rhuan Rocha Assignee: Paul Ferraro In the Wildfly 20, if I deploys two application in the same server just one registries an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13637) Invalidation caches need to consider keys in the cache store when reassigning ownership

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13637?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13637: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13392) > Invalidation caches need to consider keys in the cache store when reassigning ownership > --------------------------------------------------------------------------------------- > > Key: WFLY-13637 > URL: https://issues.redhat.com/browse/WFLY-13637 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. > This has the consequence of leaking memory for abandoned sessions. > This also impacts replication caches that contain passivated entries. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13637) Invalidation caches need to consider keys in the cache store when reassigning ownership

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13637: ----------------------------------- Summary: Invalidation caches need to consider keys in the cache store when reassigning ownership Key: WFLY-13637 URL: https://issues.redhat.com/browse/WFLY-13637 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. This has the consequence of leaking memory for abandoned sessions. This also impacts replication caches that contain passivated entries. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13636) Distributed sessions/SFSBs stored in non-transactional invalidation-cache should schedule expirations locally

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13636?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13636: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13391) > Distributed sessions/SFSBs stored in non-transactional invalidation-cache should schedule expirations locally > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13636 > URL: https://issues.redhat.com/browse/WFLY-13636 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > Currently, distributed web sessions (and SFSBs) are expired on the primary owner of the session. For non-transactional invalidation caches expiration should always be scheduled locally. This used to be the case, however, the logic for determining this has changed such that expirations happen on the owner of segment 0. > This has the consequence of an RPC cost per request (and one after). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13636) Distributed sessions/SFSBs stored in non-transactional invalidation-cache should schedule expirations locally

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13636: ----------------------------------- Summary: Distributed sessions/SFSBs stored in non-transactional invalidation-cache should schedule expirations locally Key: WFLY-13636 URL: https://issues.redhat.com/browse/WFLY-13636 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, distributed web sessions (and SFSBs) are expired on the primary owner of the session. For non-transactional invalidation caches expiration should always be scheduled locally. This used to be the case, however, the logic for determining this has changed such that expirations happen on the owner of segment 0. This has the consequence of an RPC cost per request (and one after). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13628) Invalidation caches need to consider keys in the cache store when reassigning ownership

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13628?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13628: -------------------------------- Description: On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. This has the consequence of leaking memory for abandoned sessions. was:On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. > Invalidation caches need to consider keys in the cache store when reassigning ownership > --------------------------------------------------------------------------------------- > > Key: WFLY-13628 > URL: https://issues.redhat.com/browse/WFLY-13628 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. > This has the consequence of leaking memory for abandoned sessions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13628) Invalidation caches need to consider keys in the cache store when reassigning ownership

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13628?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13628: -------------------------------- Description: On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. This has the consequence of leaking memory for abandoned sessions. This also impacts replication caches that contain passivated entries. was: On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. This has the consequence of leaking memory for abandoned sessions. > Invalidation caches need to consider keys in the cache store when reassigning ownership > --------------------------------------------------------------------------------------- > > Key: WFLY-13628 > URL: https://issues.redhat.com/browse/WFLY-13628 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > On cache topology changes, the distributed web/SFSB manager iterates over keys in memory to determine primary ownership changes. This is not sufficient for invalidation caches - which will not necessary contain those keys in memory that require rescheduling. > This has the consequence of leaking memory for abandoned sessions. > This also impacts replication caches that contain passivated entries. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020