Sapjsf locks ABAP service user psswd: M ***LOG US1= Login, Wrong Password

Question

I have a PI system and a number of ABAP systems connecting to this.
I have defined a service user in PI for each ABAP system - SY_SID_999 (where SID is the SAP System ID and 999 is the client).  Various connections (e.g., RFC, ABAP proxy) use these userid and I rely on the user name to identify the source of the activity within PI.
I was forced to change the password of one of these userids and, subsequently,  to update connection details in RFCs etc within the source system.  All went well for these connections.
Now, however, at 25 minutes past the hour, I get the following error in the PI system's developer trace
M  ***LOG US1=> Login, Wrong Password (SY_SID_999 ) [sign.c       4545]
and the SM21 log says
10:25:47 DIA  000 100 SAPJSF                  US  1 User SY_SID_999 locked due to incorrect logon
SU01 change records show no changes to SY_SID_999 from the time I unlock it until 25 minutes past the hour when this error occurs. 
The SM19 security audit log in the PI system has errors:
12.08.2009     10:08:18     SAPJSF     localhost          SAPMSSY1     Logon Failed (Reason = 53, Type = U)
Type=U means "user switch (internal call)" according to the documentation.
Reason 53 means "Too many failed password logon attempts"
These errors occur in bunches but without a consistent repetition interval.  For example, there were 8 at 10:04:56/57 then 2 at 10:08:18 then a string of success messages as follows:
12.08.2009     10:08:18     SAPJSF     localhost          SAPMSSY1     Logon Successful (Type=U)
Then, at 10:25...
12.08.2009     10:25:47     SAPJSF     localhost          SAPMSSY1     User SY_SID_999 Locked in Client 100 After Erroneous Password Checks
12.08.2009     10:25:47     SAPJSF     localhost          SAPMSSY1     Logon Failed (Reason = 1, Type = U)
If I do not unlock the SY_SID_999 userid in the PI ABAP system, there will be no further errors in SM21 but if I do, at 25 minutes past the hour after the error pattern will repeat.
I have set the rfc/logon_error_log parameter to 3 in PI ABAP to trigger a short dump.
Internal notes from the short dump do not identify the who, what or where of the sign-on attempt...
Internal notes
    The termination was triggered in function "ab_xsignon"
    of the SAP kernel, in line 2725 of the module
     "//bas/710_REL/src/krn/rfc/absignon.c#4".
    The internal operation just processed is "CALY".
    Internal mode was started at 20090812112528.
    Caller system......: " "
    Caller.............: " "
    Caller client......: " "
    RFC user ID........: " "
    RFC client.........: 100
    Login return code..: 20
    Transaction code...: " "
    (Note: In releases < 4.0, no information on the caller is available)
The source system represented by the SY_SID_999 userid is an ABAP ONLY stack so has no sapjsf userid.  (For the record, SY_SID_999 doesn't exist in client 999 of SID either - it's defined in the PI system to do work on behalf of SID client 999.)
So the question, after all that, is:
How do I identify the source of this password error?

Answer 1

Thanks Michael
I did get a short dump during the testing process and it indicates that the failed RFC logon attempt originates from within the PI system.  My implementation partner was rather careless in the assignment of userids to connections so, while this userid should only be used for connections originating from the SID, I cannot guarantee that.
I've been into both my PI system and the ABAP system (which doesn't have a sapjsf userid so should not be the offending party) and run an SQL select script to find all RFC destinations which contain the string "SID" or "sid" in any of the RFCOPTIONx fields.  I've carefully checked out each of these RFC destinations and, in SID they contain the SY_SID_999 userid and, when that's unlocked in PI, the connection and authorisation tests succeed.  That rules out upper/lower case issues and pretty much eliminates these legitimate RFC destinations from the suspect list.  The RFC destinations identified in the PI system by the SQL search contain "SID" because they name that as their target system; these definitions don't reference the SY_SID_999 userid at all.
All the evidence I can find points very strongly to some process running as SAPJSF in the Java stack of the PI (dual stack) system calling something on the ABAP side and trying to connect as SY_SID_999.  Trouble is I can't find it.  In fact, I'm don't even know where to start looking to find a job running in the Java stack - on the ABAP side I'd head for SM37 but what to use on the Java side?