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.