Hi Andreas,
Well, increasing that number does have impacts on the memory foot-print
and overall responsiveness. So, eventually that would need to be addressed
in a more comprehensive way. The issues here are
a) Increasing the number of bytes sent to the cmsd decreases its
responsiveness.
b) The 2k limit should have accomodated a 1k path (the max you can have
for any filesystem) and 1k (roughly) of opaque info which would seem to be
sufficient for reasonable interactions that don't try to overload the
opaque info. This may encourage people to unecessarily overload the opaque
info.
c) This may allow people to be even more sloppy and not trim redundant
opaque information from the request. I see it on the web all the
time where each application layer simply appends its cgi string to the
existing string and the stuff grows without bound eventhough the appended
string duplicates many pre-existing elements. This is just sloppy and
slows everything down.
So, let's start with a recommendation for the smallest resonable increase.
What did you have in mind?
Andy
On Mon, 20 Sep 2010, Andreas-Joachim Peters wrote:
> Currently the file path is limited to <2kb because XrdOucErr is used as an
> object for redirection.
> struct XrdOucEI // Err information structure
> {
> static const size_t Max_Error_Len = 2048;
> ....
>
>
> Is there any objection/problem to increase this? Because as far as I
> understood the path is not really limited in the protocl but in the
> redirection mechanism?!?!?
>
> I run quickly into trouble because experiments use very long path names and
> I also need to add some opaque information which is included in the 2kb.
>
> Cheers Andreas.
>
