jonathan

	Last Week	All Time
Commits:	0	51
Files changed:	0	19
Change in LOC:	0	387

committed 1976 to openam

16 May

Fixed unit tests, introduced ordering of tests

modified CoreTokenServiceTest.java

branches/oauth2-branch/opensso/extensions/oauth2/.../forgerock/openam/ext/cts/CoreTokenServiceTest.java (+6 -4)
- Diff
- View
- File History
- Download

jonathan

replied to Peter Major in CR-399

23 Apr

Hmm, that might be excessive; for a bugfix we should stick close to the original approach if possible. As far as I can tell, the code you are replacing here will remove the need for the .configParams file.

1) If we are not going to read the .configParams file then we probably don't want to generate it, and should remove this from the AMSetupServlet
2) If we do want to generate it then we should probably fix the logic in AMSetupServlet.checkBaseDir(...) so it handles the existing dir case, and have this new code kick in only if the file cannot be found. Ie: file first, then your defaults.

I'd suggest checking with Steve if this file is useful to support, or if we it was originally introduced to prevent retyping if the configurator fails, which would still be a valid feature.

jonathan

finished reviewing CR-399

23 Apr

jonathan

commented on CR-399

23 Apr

        parameters.put(SetupConstants.CONFIG_VAR_DS_MGR_PWD, "********");

This line and the follow lines make the code in AMSetupServlet that overrides value with "********" redundant and unclear at first glance where the values in the file are being determined. I'd suggest either removing the check in AMSetupServlet (checking that there is no other possible IHttpServletRequest that may be passed to the servlet) or set the values here to null for password fields.

jonathan

changed the Fix Version/s to '10.0.1' on OPENAM-1241

17 Apr

Fixed fix versions

jonathan

updated 2 fields of OPENAM-1242

17 Apr

Fixed versions

jonathan

resolved OPENAM-1242, OPENAM-1241

17 Apr

jonathan

committed 1928 to openam

17 Apr

Backport of OPENAM-1241 to 95 sustaining branch

modified ThreadPool.java

branches/openam_snapshot95_sustaining_branch/opensso/products/.../iplanet/am/util/ThreadPool.java (+1 -1)
- Diff
- View
- File History
- Download

jonathan

committed 1927 to openam

17 Apr

Backporting fix for OPENAM-1241

modified ThreadPool.java

branches/openam_10_sustaining/opensso/products/amserver/source/com/iplanet/am/util/ThreadPool.java (+1 -1)
- Diff
- View
- File History
- Download

jonathan

committed 1924 to openam

16 Apr

OPENAM-1241

modified ThreadPool.java

trunk/opensso/products/amserver/source/com/iplanet/am/util/ThreadPool.java (+1 -1)
- Diff
- View
- File History
- Download

jonathan

updated 3 fields of OPENAM-1253

16 Apr

Changed severity from critical to major, since there is a clear workaround. Slated for 10.1

jonathan

changed the Priority to 'Major' on OPENAM-111

16 Apr

Severity changed from critical to major, since this impairs but does not break functionality, and there is a clear workaround as stated by Peter. Should target 10.1 for fix.

jonathan

changed the Link to 'This issue relates to OPENAM-1242' on OPENAM-1241

15 Apr

jonathan

changed the Link to 'This issue is related to OPENAM-1241' on OPENAM-1242

15 Apr

I believe this issue shares the same root cause as ~~OPENAM-1241~~, since the relevant context is identical (OSX, Java 1.6u31, SMS work threads in the ThreadPool). The conclusion was that this was due to spurious wakeups occuring on OSX in this JVM update.

I suggest that this is retested when the patch in ~~OPENAM-1241~~ is committed post-release.

jonathan

commented on OPENAM-1241

13 Apr

Patch:

Index: source/com/iplanet/am/util/ThreadPool.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- source/com/iplanet/am/util/ThreadPool.java (revision 1910)
+++ source/com/iplanet/am/util/ThreadPool.java (revision )
@@ -289,7 +289,7 @@
             while (true) {
                 try{
                     synchronized (this) {
- if ((task == null) && (!shouldTerminate)){
+ while ((task == null) && (!shouldTerminate)){
                             this.wait();
                         }
                         // need a local copy because they may be changed after

jonathan

commented on OPENAM-1241

13 Apr

Here is the conclusion regarding the concurrency bug observed on OSX/Oracle JDK 1.6u31

From testing upgrade about 50 times under controlled conditions but without reducing the execution speed, the error could be consistently reproduced. ThreadPool in OpenAM has an array of WorkerThread objects that execute Runnable tasks; when a task is to be executed, the next available thread is taken from the array and made unavailable until it has completed the work required, when it is added back to the array. The pool for the SMS service has 10 threads.
This error occurs when a thread is notified at *almost* the same time as a thread is returned to the pool to wait() (<1 millisecond) where both threads are returned but the second thread is then notified again immediately (<1 millisecond) without any task being queued for execution or the shutdown signal being given.

The root cause for this is I believe a "spurious wakeup", where threads may be awoken without notification being triggered explicitly in the application. This is mentioned in the standard as something that must be tolerated, and it boils down to the specifics of the JVM implementation. This harmonizes well with the observations that behaviour changes with the JVM version.

The solution is to take into account that a thread may be awoken by mistake, and should go back to sleep if so. In the code the wait() is executed in an if(...) block; replacing this with while(...) solves the problem.

jonathan

commented on OPENAM-1241

11 Apr

Stepping through this with a debugger during upgrade, the upgrade succeeded. Letting the upgrade run at full speed caused the error again.

I suspect that there is a synchronization issue or other concurrency issues at the root of this, possibly in the JDK. When returning to this, it would be good to take a look at ThreadPool and known issues in Oracle JVM 1.6.0_31

jonathan