I am using the standalone server. BTW, the password is seen right after
the change AND after a reboot of the standalone server, so the password
change is permanent - even if not written to disk immediately. The
problem still remains that between the time it is changed by the webapp
and before the reboot of the LDAP server, webapp attempts to bind with
the new password fail, but binding with the old password works.
Weird...
I will upgrade to 1.5.4 in the meantime and let you know if this is
fixed. Are there any config migration tools and/or tips? Will LDIF
export/import just work?
Thanks for all your insight so far!
Rich
Emmanuel Lecharny wrote:
Rich Remington wrote:
Thanks for the feedback! It appears that I need to try the upgrade
as I do have the synchOnWrite=true already. Where can I find 1.5.4
today?
You can't, as the mirror are just being updated, and it takes time. As
soon as the mirrors will be ok, we will update the download pages.
However, you can build the installer for your platform from the code :
http://directory.apache.org/apacheds/1.5/building-trunks.html#Buildingtrunks-Buildingtheinstallers
Also, I am still confused about the scenario I am experiencing. The
webapp is the one responsible for making the password change, which
is then seen by the Studio app right afterward.
The webapp will transmit the new password to the LDAP server, which is
responsible for the password storage. And the LDAP server 'sees' the
password, as you can check it with Studio.
So, if the cache has the change, it seems that the cache should be
used for future bind requests by either the webapp or Studio.
The cache will be used, that's for sure.
It really shouldn't matter if it has hit the disk yet, should it?
It does, because if the password is just in the cache, and not on the
disk, when you shutdown the webapp (thus the LdapServer), the password
just disappear...
Are you embedding the server in your webapp, btw ?
