[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-6452:
----------------------------------------
Because there are many HTTP mechanisms where associating an authenticated identity with a session is a bad practice so the caching is now deferred to the JBossCachedAuthenticationManager.
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Juan AMAT (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Juan AMAT commented on WFLY-6452:
---------------------------------
I am not sure if I understand. The user has already been authenticated and the session is still valid.
So why do we need this call? Again in EAP this is not the case.
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-6452:
----------------------------------------
isValid() is called on every request so we have a single cache to make the decision as to if additional authentication is required. I agree however that this would benefit from the cache being tunable to avoid this situation with a large number of users.
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-6452:
-----------------------------------
Component/s: Security
(was: Security Manager)
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-6452:
--------------------------------------
Assignee: Darran Lofthouse (was: Stefan Guilhen)
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
> Priority: Critical
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-6452:
-----------------------------------
Priority: Major (was: Critical)
> JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6452
> URL: https://issues.jboss.org/browse/WFLY-6452
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juan AMAT
> Assignee: Darran Lofthouse
>
> While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
> What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
> In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
> With wildfly it was 95+%.
> Threads dumps showed a lot of threads in the JAAS Login Module.
> We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
> This was strange because all the users were already authenticated.
> It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
> The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
> The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
> We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
> But this is just a workaround IMO.
> Why is 'isValid' called on every request in Wildfly?
> On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6452) JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
by Juan AMAT (JIRA)
Juan AMAT created WFLY-6452:
-------------------------------
Summary: JBossCachedAuthenticationManager.isValid is called on every http requests of an authenticated user
Key: WFLY-6452
URL: https://issues.jboss.org/browse/WFLY-6452
Project: WildFly
Issue Type: Bug
Components: Security Manager, Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Juan AMAT
Assignee: Stefan Guilhen
Priority: Critical
While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4.
What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average.
In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM.
With wildfly it was 95+%.
Threads dumps showed a lot of threads in the JAAS Login Module.
We are using org.jboss.security.auth.spi.DatabaseServerLoginModule.
This was strange because all the users were already authenticated.
It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4.
The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients.
The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication.
We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker).
But this is just a workaround IMO.
Why is 'isValid' called on every request in Wildfly?
On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-101:
---------------------------------------
Ah I see what you mean. In the ideal world you throw what you have as your cause, but with the test from the {{@Message}} prepended to the current message text.
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-101:
-------------------------------------
No, I mean that the new exception's stack trace is exactly the same as the old exception's stack trace. Basically this is the only way you can change the message text of an exception since that value is immutable. You have to construct a new exception of the same type as the original but with the modified message text, then you have to copy the stack trace of the original into the new object.
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-101:
---------------------------------------
Do you want the stack trace just appended to the created exceptions stack trace? So something like:
{code:java}
final StackTraceElement[] resultStackTrace = result.getStackTrace();
final StackTraceElement[] causeStackTrace = cause.getStackTrace();
final int newLen = resultStackTrace.length + causeStackTrace.length;
final StackTraceElement[] newStackTrace = Arrays.copyOf(resultStackTrace, newLen);
System.arraycopy(causeStackTrace, 0, newStackTrace, resultStackTrace.length, causeStackTrace.length);
result.setStackTrace(newStackTrace);
{code}
WRT cloning I'm not sure I get what you mean.
Note I'll also fix the {{@Pos}} documentation as it's rather poor :)
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month