[JBoss JIRA] (WFLY-7119) Introduce new web session granularity for consistent fine granularity replication
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7119?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7119:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Introduce new web session granularity for consistent fine granularity replication
> ---------------------------------------------------------------------------------
>
> Key: WFLY-7119
> URL: https://issues.jboss.org/browse/WFLY-7119
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 13.0.0.Beta1
>
>
> Currently, ATTRIBUTE granularity sessions are vulnerable to partial stale reads, where some session attributes might have current data, and some are stale. For some use cases, this might be intolerable. For these use cases, we should introduce a new session granularity that tracks a version or checksum per attribute, that we can use to detect stale attribute cache entries.
> This new granularity would retain the performance benefits of ATTRIBUTE granularity replication while maintaining the attribute consistency guarantees of SESSION granularity replication.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-8449) EJB contextData not sent back to client in response
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-8449?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-8449:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> EJB contextData not sent back to client in response
> ---------------------------------------------------
>
> Key: WFLY-8449
> URL: https://issues.jboss.org/browse/WFLY-8449
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Fedor Gavrilov
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency, ejb
> Fix For: 13.0.0.Beta1
>
>
> With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-7537) Review NamingContext.check() method
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7537?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7537:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Review NamingContext.check() method
> -----------------------------------
>
> Key: WFLY-7537
> URL: https://issues.jboss.org/browse/WFLY-7537
> Project: WildFly
> Issue Type: Task
> Components: Naming
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 13.0.0.Beta1
>
>
> The new naming client is sending in a SimpleName where the lookup was performed using a String.
> When a SecurityManager is installed the check() method of NamingContext is called and results in the following error: -
> {noformat}
> javax.naming.InvalidNameException: Not a composite name: jms
> at javax.naming.CompositeName.addAll(CompositeName.java:472)
> at org.jboss.as.naming.NamingContext.check(NamingContext.java:592)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
> 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:745)
> {noformat}
> A fix has been applied to convert the incoming name to a CompositeName but as we deliberately have a SimpleName to avoid CompositeName I wonder if that is completely correct.
> Some other options I think of: -
> 1. Stick with current fix.
> 2 The client should convert to CompositeName before sending.
> 3. Manually iterate the segments if not a CompositeName
> 4. Check if the NamingStore really needs to use a CompositeName
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months