jonathan

jonathan

committed 1976 to openam

16 May
Fixed unit tests, introduced ordering of tests
jonathan

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
        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

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

attached one file to OPENAM-1241

10 Apr
jonathan

created OPENAM-1241

10 Apr
jonathan

committed 1867 to openam

02 Apr
Added static parameters, although these probably need to be refactored out into a different package
jonathan

committed 1866 to openam

02 Apr
Updated to use new domain model (JsonValue domain objects)
jonathan

committed 1862 to openam

02 Apr
Added dependency on OpenAM restlet extension, to be reviewed