[JBoss JIRA] (WFCORE-2943) Runtime attribute loaded-providers of elytron provider-loader should not be required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2943?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2943:
------------------------------------------
This change is ok, but not because these are runtime-only attributes. It's ok for a runtime-only attribute to be required. (They can have an undefined value in a response if the read-resource op doesn't include the include-runtime=true param, but that doesn't count in terms of the attribute being "required" or not. The "storage" metadata for the attribute covers that.)
These should be required=false because looking at the read handler impls it looks like the user can use include-runtime=true and still get an undefined value for these, i.e. if the relevant service is not up.
> Runtime attribute loaded-providers of elytron provider-loader should not be required
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2943
> URL: https://issues.jboss.org/browse/WFCORE-2943
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta26
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Runtime attribute being required (and thus nillable false) is confusing for users.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8904) Fix AuthenticationTestCase and GetCallerPrincipalTestCase for Elytron and unignore it
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8904?page=com.atlassian.jira.plugin.... ]
Kabir Khan reopened WFLY-8904:
------------------------------
> Fix AuthenticationTestCase and GetCallerPrincipalTestCase for Elytron and unignore it
> -------------------------------------------------------------------------------------
>
> Key: WFLY-8904
> URL: https://issues.jboss.org/browse/WFLY-8904
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Michal Jurc
> Assignee: Michal Jurc
> Fix For: 11.0.0.Beta1
>
>
> {{org.jboss.as.test.integration.ejb.security.AuthenticationTestCase}} currently fails in {{elytron}} profile due to different exception than expected (old PB one) being produced by Elytron:
> {code}Results :
> Failed tests:
> AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:257 null
> {code}
> When this is fixed, the test should be unignored for the {{elytron}} profile.
> {{GetCallerPrincipalTestCase}} also needs to be changed to adhere to unspecified security context in beans in {{PostConstruct}} phase.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-8920 at 6/13/17 11:56 AM:
------------------------------------------------------------------
I have my doubts this is a bug.
You've deployed the app. It's deployed using the resources available to it at that time. Now some other resources are created, and the expectation is the already deployed app should automagically take advantage of those new resources.
What happens if you deploy a new app, after the /subsystem=ejb3/application-security-domain=other:add but without a reload? I believe it will pick up ApplicationDomain.
-I believe this behavior is intentional; IIRC this has come up in the past and been confirmed as such.-
So: why not just say "reload-required" anyway, just in case? That's because if a capability (which there is here) goes reload-required, then further changes to that cap or caps that depend on it will no longer execute runtime changes. So, adding "reload-required" is going to have side effects and isn't something we should just do.
was (Author: brian.stansberry):
I have my doubts this is a bug.
You've deployed the app. It's deployed using the resources available to it at that time. Now some other resources are created, and the expectation is the already deployed app should automagically take advantage of those new resources.
What happens if you deploy a new app, after the /subsystem=ejb3/application-security-domain=other:add but without a reload? I believe it will pick up ApplicationDomain.
-I believe this behavior is intentional; IIRC this has come up in the past and been confirmed as such.-
So: why not just say "reload-required" anyway, just in case? That's because if a capability (which there eventually will be here) goes reload-required, then further changes to that cap or caps that depend on it will no longer execute runtime changes. So, adding "reload-required" is going to have side effects and isn't something we should just do.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-8920 at 6/13/17 11:55 AM:
------------------------------------------------------------------
I have my doubts this is a bug.
You've deployed the app. It's deployed using the resources available to it at that time. Now some other resources are created, and the expectation is the already deployed app should automagically take advantage of those new resources.
What happens if you deploy a new app, after the /subsystem=ejb3/application-security-domain=other:add but without a reload? I believe it will pick up ApplicationDomain.
-I believe this behavior is intentional; IIRC this has come up in the past and been confirmed as such.-
So: why not just say "reload-required" anyway, just in case? That's because if a capability (which there eventually will be here) goes reload-required, then further changes to that cap or caps that depend on it will no longer execute runtime changes. So, adding "reload-required" is going to have side effects and isn't something we should just do.
was (Author: brian.stansberry):
I have my doubts this is a bug.
You've deployed the app. It's deployed using the resources available to it at that time. Now some other resources are created, and the expectation is the already deployed app should automagically take advantage of those new resources.
What happens if you deploy a new app, after the /subsystem=ejb3/application-security-domain=other:add but without a reload? I believe it will pick up ApplicationDomain.
I believe this behavior is intentional; IIRC this has come up in the past and been confirmed as such.
So: why not just say "reload-required" anyway, just in case? That's because if a capability (which there eventually will be here) goes reload-required, then further changes to that cap or caps that depend on it will no longer execute runtime changes. So, adding "reload-required" is going to have side effects and isn't something we should just do.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8920:
----------------------------------------
I believe there's some other ejb3 subsystem setting that has a semantic similar to what we see here. I forget what it is; TBH I thought this JIRA was about it but I see now this is a new config item.
Found it. It's here:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
That OSH updates the internal state of a DeploymentUnitProcessor. That means future deployments (or a redeploy) will pick up the new value, but existing deployments do not.
There may be others as well; there are a few "default xyx" settings in the subsystem.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2171?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2171.
----------------------------
Resolution: Done
This JIRA resulted in 2 new bundlers: {{AlternatingBundler}} and {{RemoveQueueBundler}} (both marked as experimental).
The first will probably be removed again, and we need to experiment further with the second, which shows performance similar to {{TransferQueueBundler}}.
Seems we've reached a glass ceiling with bundler since none of the recent bundler implementations surpasses the existing bundlers (TransferQueueBundler, RingBufferBundler)...
> New bundler with max_bundle_size for each destination
> -----------------------------------------------------
>
> Key: JGRP-2171
> URL: https://issues.jboss.org/browse/JGRP-2171
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.
> This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).
> The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.
> This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).
> We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.
> So 1 main queue and 1 queue for each destination.
> h4. Example:
> * {{num_flips}} is 2
> * A message for A is sent, added to the main queue and removed by the runner. It is queued in A's queue
> * Another message for A is sent. Also queued (A's queue: {{A A}})
> * A message to B is sent: A's {{num_flips}} is now 1. A's queue is {{A A}}, B's queue is {{B}}
> * Another message to A is sent. This resets A's {{num_flips}} to 2, B's {{num_flips}} is now 1
> * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
> * No more messages are received, so the batch to C is also sent
> The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).
> h4. Misc
> * Should the sending of batches be delegated to a thread pool?
> * Should the senders add their messages directly to the destination queues instead of the main queue? That would result in less contention on the main queue, but it would also require 1 thread per destination queue, which creates too many threads...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-8920:
----------------------------------------
It would be much more complex (And probably not worth it) - but an alternative could be to track the security domains used by deployments that don't match an application-security-domain, if we add an application-security-domain that would match then trigger the reload required and in all other cases do nothing.
TBH though this isn't really a resource we expect to be used in this way, we have added this mapping to support Elytron and PicketBox in parallel we are not really expecting runtime switching between the two security solutions.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8920:
----------------------------------------
I have my doubts this is a bug.
You've deployed the app. It's deployed using the resources available to it at that time. Now some other resources are created, and the expectation is the already deployed app should automagically take advantage of those new resources.
What happens if you deploy a new app, after the /subsystem=ejb3/application-security-domain=other:add but without a reload? I believe it will pick up ApplicationDomain.
I believe this behavior is intentional; IIRC this has come up in the past and been confirmed as such.
So: why not just say "reload-required" anyway, just in case? That's because if a capability (which there eventually will be here) goes reload-required, then further changes to that cap or caps that depend on it will no longer execute runtime changes. So, adding "reload-required" is going to have side effects and isn't something we should just do.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months