[JBoss JIRA] (WFLY-9917) renewal of server certificate for Undertow without restarting server
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9917?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-9917:
----------------------------------
If you switch keystore files (put new one on path of old one), you are able to do the reload using:
{code}
/subsystem=elytron/key-store=newKS:load()
/subsystem=elytron/key-manager=newKM:init()
{code}
This will ensure new keystore file will start to be used.
*But this will NOT ensure any model changes (like attribute alias-filter) become effective* - this would be new feature.
> renewal of server certificate for Undertow without restarting server
> --------------------------------------------------------------------
>
> Key: WFLY-9917
> URL: https://issues.jboss.org/browse/WFLY-9917
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 11.0.0.Final
> Reporter: Hisanobu Okuda
> Assignee: Darran Lofthouse
>
> It is convenient that a server certificate for https interface can be renewed without restarting a server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBVFS-188) TimedCachePolicy using unsynchronized Map by default
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBVFS-188?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved JBVFS-188.
-------------------------------
Resolution: Out of Date
> TimedCachePolicy using unsynchronized Map by default
> ----------------------------------------------------
>
> Key: JBVFS-188
> URL: https://issues.jboss.org/browse/JBVFS-188
> Project: JBoss VFS
> Issue Type: Bug
> Components: Release
> Affects Versions: 2.2.0.SP1
> Reporter: Keiichi Sato
>
> TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
> at java.util.HashMap$EntryIterator.next(HashMap.java:851)
> at java.util.HashMap$EntryIterator.next(HashMap.java:849)
> at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
> at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
> at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
> at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
> at org.jboss.virtual.VFS.getRoot(VFS.java:243)
> at org.jboss.virtual.VFS.getRoot(VFS.java:313)
> {noformat}
> When JBoss starts with the default configuration, the following output in boot.log.
> {noformat}
> 21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
> {noformat}
> This does not mean TimedCachePolicy is threadSafe
> {code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
> protected TimedCachePolicy createCachePolicy()
> -- snip --
> log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
> TimedCachePolicy tcp;
> if (defaultLifetime == null)
> tcp = new TimedCachePolicy();
> else if (resolution != null)
> tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
> else
> tcp = new TimedCachePolicy(defaultLifetime);
> -- snip --
> {code}
> If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
> {code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
> public TimedCachePolicy()
> {
> this(30*60, false, 0);
> }
> {code}
> The default constructor specifies threadSafe to false.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBVFS-188) TimedCachePolicy using unsynchronized Map by default
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBVFS-188?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned JBVFS-188:
---------------------------------
Assignee: (was: David Lloyd)
> TimedCachePolicy using unsynchronized Map by default
> ----------------------------------------------------
>
> Key: JBVFS-188
> URL: https://issues.jboss.org/browse/JBVFS-188
> Project: JBoss VFS
> Issue Type: Bug
> Components: Release
> Affects Versions: 2.2.0.SP1
> Reporter: Keiichi Sato
>
> TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
> at java.util.HashMap$EntryIterator.next(HashMap.java:851)
> at java.util.HashMap$EntryIterator.next(HashMap.java:849)
> at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
> at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
> at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
> at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
> at org.jboss.virtual.VFS.getRoot(VFS.java:243)
> at org.jboss.virtual.VFS.getRoot(VFS.java:313)
> {noformat}
> When JBoss starts with the default configuration, the following output in boot.log.
> {noformat}
> 21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
> {noformat}
> This does not mean TimedCachePolicy is threadSafe
> {code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
> protected TimedCachePolicy createCachePolicy()
> -- snip --
> log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
> TimedCachePolicy tcp;
> if (defaultLifetime == null)
> tcp = new TimedCachePolicy();
> else if (resolution != null)
> tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
> else
> tcp = new TimedCachePolicy(defaultLifetime);
> -- snip --
> {code}
> If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
> {code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
> public TimedCachePolicy()
> {
> this(30*60, false, 0);
> }
> {code}
> The default constructor specifies threadSafe to false.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBAS-9537) AsyncAppender and URLWatchTimerTask deadlock
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-9537?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned JBAS-9537:
---------------------------------
Assignee: (was: David Lloyd)
> AsyncAppender and URLWatchTimerTask deadlock
> --------------------------------------------
>
> Key: JBAS-9537
> URL: https://issues.jboss.org/browse/JBAS-9537
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Components: Logging
> Affects Versions: JBossAS-4.2.1.GA
> Environment: CentOS release 5.9, JBoss 4.2.1, Oracle Java 1.7.0_21, VMWare virtual machine
> Reporter: Theodore Lizard
>
> Logging stops if AsyncAppender's buffer is full and logging is reconfigured.
> Example: I want to get detailed logs of something so I modify jboss-log4j.xml and change priority of some category to DEBUG. I tail the log file and it stops. Stackdump reveals the following:
> "Timer-0" daemon prio=10 tid=0x000000001c956000 nid=0x8b1 in Object.wait() [0x00002ae22e8c0000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Unknown Source)
> - locked <0x0000000096a71230> (a java.lang.Thread)
> at java.lang.Thread.join(Unknown Source)
> at org.apache.log4j.AsyncAppender.close(AsyncAppender.java:240)
> at org.apache.log4j.helpers.AppenderAttachableImpl.removeAllAppenders(AppenderAttachableImpl.java:140)
> at org.apache.log4j.Category.removeAllAppenders(Category.java:868)
> - locked <0x00000000c850b4e0> (a org.apache.log4j.spi.RootLogger)
> at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:410)
> at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:394)
> - locked <0x00000000c850b4e0> (a org.apache.log4j.spi.RootLogger)
> at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:829)
> at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
> at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
> at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:743)
> at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:643)
> at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:582)
> at java.util.TimerThread.mainLoop(Unknown Source)
> at java.util.TimerThread.run(Unknown Source)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík commented on WFLY-9913:
---------------------------------
[~rhusar] I don't think so. There is wait until each worker starts sending STATUS message to balancer with expected load. AFAIK no re-registration of either workers or contexts is expected after this 'verification'. Or is it?
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and verification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> This occurs only on EAP/Wildlfly balancer and we suspect, that this is an error in Undertow mod_cluster implementation. The problem is, that sometimes more requests than expected ends up on the worker with lowest load:
> {{java.lang.AssertionError: Assert #5, Request distribution according to the load was supposed to be [jboss-eap-7.2-1:106, jboss-eap-7.2-2:106, jboss-eap-7.2-3:789] with tolerance +/-10, but was: [jboss-eap-7.2-1:36, jboss-eap-7.2-2:35, jboss-eap-7.2-3:930]}}
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9937) Enable CompensationScopedTestCase as it was disabled based on intermittent failures
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-9937:
-------------------------------------
Summary: Enable CompensationScopedTestCase as it was disabled based on intermittent failures
Key: WFLY-9937
URL: https://issues.jboss.org/browse/WFLY-9937
Project: WildFly
Issue Type: Bug
Components: Test Suite, XTS
Affects Versions: 12.0.0.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
Priority: Minor
The CompensationScopedTestCase should be enabled again.
It was disabled based on the intermittent failures at jira WFLY-9871. See the discussion there for more details.
>From my review it sounds that this could be a functional issue but it's hard to say as I was not able to reproduce the behaviour.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9937) Enable CompensationScopedTestCase as it was disabled based on intermittent failures
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9937?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated WFLY-9937:
----------------------------------
Steps to Reproduce:
I simulated the ordering of the tests as it was in the failing CI job - you can check here, it's hacky way:
https://github.com/ochaloup/wildfly/tree/WFLY-9871-reordering-testcases
for decreasing number of thread to be used the {{io}} subsystem could be changed.
{code}
<subsystem xmlns="urn:jboss:domain:io:2.0">
<worker name="default" task-max-threads="3" io-threads="3" />
<buffer-pool name="default"/>
</subsystem>
{code}
Tried to run with elytron as it was the case where intermittent failures happened. No idea about relationship of the issue and the elytron.
{code}
cd testsuite/integration/xts
mvn test -Delytron
{code}
was:
I simulated the ordering of the tests as it was in the failing CI job - you can check here, it's hacky way:
https://github.com/ochaloup/wildfly/tree/WFLY-9871-reordering-testcases
for decreasing number of thread to be used the {{io}} subsystem could be changed.
Tried to run with elytron as it was the case where intermittent failures happened. No idea about relationship of the issue and the elytron.
{code}
cd testsuite/integration/xts
mvn test -Delytron
{code}
> Enable CompensationScopedTestCase as it was disabled based on intermittent failures
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9937
> URL: https://issues.jboss.org/browse/WFLY-9937
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, XTS
> Affects Versions: 12.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Minor
>
> The CompensationScopedTestCase should be enabled again.
> It was disabled based on the intermittent failures at jira WFLY-9871. See the discussion there for more details.
> From my review it sounds that this could be a functional issue but it's hard to say as I was not able to reproduce the behaviour.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1532) Deprecate AuthConf setHost, setProtocol, setPort properties
by David Lloyd (JIRA)
David Lloyd created ELY-1532:
--------------------------------
Summary: Deprecate AuthConf setHost, setProtocol, setPort properties
Key: ELY-1532
URL: https://issues.jboss.org/browse/ELY-1532
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: David Lloyd
Priority: Critical
We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9913:
--------------------------------------
[~jkasik] Is there any chance the test is buggy and does not leave enough time for all the worker nodes and contexts to be registered?
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and verification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> This occurs only on EAP/Wildlfly balancer and we suspect, that this is an error in Undertow mod_cluster implementation. The problem is, that sometimes more requests than expected ends up on the worker with lowest load:
> {{java.lang.AssertionError: Assert #5, Request distribution according to the load was supposed to be [jboss-eap-7.2-1:106, jboss-eap-7.2-2:106, jboss-eap-7.2-3:789] with tolerance +/-10, but was: [jboss-eap-7.2-1:36, jboss-eap-7.2-2:35, jboss-eap-7.2-3:930]}}
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9702:
---------------------------------
Fix Version/s: (was: 13.0.0.Beta1)
> SSO Integration for Programmatic Authentication
> -----------------------------------------------
>
> Key: WFLY-9702
> URL: https://issues.jboss.org/browse/WFLY-9702
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
>
> At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.
> In this scenario we don't have either a wrapped mechanism or a CallbackHandler.
> Couple of options: -
> * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on.
> * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication?
> * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
> *
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months