Print

Print


Hi Andy,
I solved it now exactly in your recommended way to eliminate redundant
information, so let's leave it like tis is ;-)
I agree on your argumentation. 1k+1k should be doable for almost everything.

Cheers Andreas.


On Tue, Sep 21, 2010 at 6:23 PM, Andrew Hanushevsky
<[log in to unmask]>wrote:

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