I have now tested the current production DPM and Castor SRM
implementations, these servers do not care where the WSDL is downloaded
from while D-Cache is following the standard more accurately, this is
essential for both SRM v1 and v2 to coexist on the same port.
Tigran has found a work around to this bug. The client code does not use
the variable in
".srmconfig/config.xml"
<webservice_path>
for dcache-client-1.6.6-5
which is now used in client
dcache-client-1.6.7-3
unfortunately this is set to the wrong value in the default
configuration. The default configuration sets this value to
srm/managerv1.wsdl for both clients. While the correct value should be
"srm/managerv1".
Tigran found this error by scanning the service challenge logs and this
appears to be a problem of misconfiguration of the client as the server
location for the wsdl has not changed and is being read by clients other
than srmcp.
Apologies all round for not identifying this bug before release. I
thought I had tested this but it appears that I must only have tested
srmcp with the dcache-client-1.6.6-5 version thinking it was the
dcache-client-1.6.7-3.
The impact of this error is that all ".srmconfig/config.xml" need to be
changed to have a webservice_path changed from "srm/managerv1.wsdl" to
"srm/managerv1".
All users who do not have this file will have this file misconfigured in
the release previously tested and I will be testing the new prerelease
for upgrading this solution later this afternoon.
This will fix this bug by ignoring the ".wsdl" extension if it exists in
the client to keep things backward compatible. expect an anouncment within
24 hours.
Regards
Owen Synge
On Tue, Jun 06, 2006 at 02:26:46PM +0100, Jensen, J (Jens) wrote:
> Which is why we need release procedures and testing and all that.
Of course. The problem is that there is nothing in place at the
moment judging from the quality of some dcache releases and I
suspect things will get worse and not better once RAL drops dcache.
> >From your description, it sounds like the server doesn't return
> the wsdl which will make srmcp refuse to connect. Try another
> client - I don't think GFAL fetches the wsdl. Or FTS.
Just downgrading the dcache client is enough so I suspect that the
server is OK and the client release with the CA fixes is broken.
Cheers,
Kostas
-----Original Message-----
From: GRIDPP2: Deployment and support of SRM and local storage management on behalf of Kostas Georgiou
Sent: Tue 6/6/2006 2:40 PM
To: [log in to unmask]
Subject: Re: dCache CA problem
On Tue, Jun 06, 2006 at 02:26:46PM +0100, Jensen, J (Jens) wrote:
> Which is why we need release procedures and testing and all that.
Of course. The problem is that there is nothing in place at the
moment judging from the quality of some dcache releases and I
suspect things will get worse and not better once RAL drops dcache.
> >From your description, it sounds like the server doesn't return
> the wsdl which will make srmcp refuse to connect. Try another
> client - I don't think GFAL fetches the wsdl. Or FTS.
Just downgrading the dcache client is enough so I suspect that the
server is OK and the client release with the CA fixes is broken.
Cheers,
Kostas
|