Re: Sniffer/Stats Issues Reviewed

St.Ego wrote:
> Jason wrote:
>> St.Ego wrote:
>>   
>>>> ...
>>>> There's also very little reason why a UA string needs to be more than 
>>>> 255 characters.  The one Chad discovered could be considered malformed, 
>>>> as it had an extraneous version/platform declaration and, being based on 
>>>> Windows media center/IE, had three .NET CLR versions and the specific 
>>>> developer's URL, 283 characters in all.
>>>>       
>>> FWIW, approximately 1/5 to 1/3 of all the Sniffer table entries were
>>> truncated at max length to fit the field prior to the upgrade on that
>>> client site. I believe the issue is MUCH more widespread than it may be
>>> perceived.
>>>     
>>
>> Perhaps we just need to make sure the entry is truncated to a length *we* set
>> before we attempt to process it. The error being fixed here is one of an
>> unexpected duplicate key due to the fact that we checked the existing
>> (truncated) data against the incoming (not-truncated) data. Make sure both are
>> truncated to avoid such an error.
>>
>> However, there are still race conditions possible, so perhaps the 'duplicate
>> key' error should just be caught anyway and a further lookup performed to check
>> whether another session has written the UA same string since we did a lookup
>> (finding it not to be there).
>>
>> -- Jason
> Keeping it truncated would be more of a convenience as a workaround,
> IMO. The changes submitted correct the issue instead of working around
> it, which would seem preferable, no?
> 
> -St.Ego

I wouldn't say it was a workaround. I would say we would be protecting ourselves
 by setting limits. What is the limit at the moment? If we get sent a thousand
32kbyte agent strings, what would happen? The limits need to be set in Xaraya.

How long is the index for the UA string? Being a text field now, the index only
covers a certain number of characters. If we get too many long strings, what
impact does that have on performance?

Just saying, there is always a lot to think about, especially when dealing with
incoming data that we have no control over.

-- JJ