[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13639?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13639:
--------------------------------
Description:
Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs.
By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
was:By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
> Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
> -----------------------------------------------------------------------------------
>
> Key: WFLY-13639
> URL: https://issues.redhat.com/browse/WFLY-13639
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs.
> By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13639:
-----------------------------------
Summary: Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
Key: WFLY-13639
URL: https://issues.redhat.com/browse/WFLY-13639
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 20.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[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 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 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.
> 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 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)
5 years, 10 months
[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 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.
> 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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months