Jump to content

Sasun Steinbeck

Resident
  • Content Count

    234
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Sasun Steinbeck

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah it's so rare that bombarding my server with umpteen million of the same POSTs for a few months seems like a long shot. I definitely can't even imagine how to reproduce them on demand. I can't see a pattern - in frequency, or the position of truncation, or the originating script name, or region.. but I just realized I've been lax on saving these records for very long so I'll see if there's any kind of date/time pattern, thanks for the suggestion. Don't have enough data to rule that out...
  2. That's a great thought. But in this case, that's not happening. Sometimes the truncation happens right in the middle of a hard-coded parameter name rather than something I'm pulling from the database. And those parameter names don't have any special characters in them. For example in the middle of the string I have "param1=customer_name" or something and it truncates right in the middle of "param1". I've gone over and over my LSL code that's making the HTTP call thinking it must be truncating it here, and that's always a valid possibility, but I really don't think so. I probably get a half million HTTP requests per week and only a few get chopped up like this. And again, I might get two in a row, truncated in different positions on what is almost an identical data string, coming from different scripts in different regions so... I really do not suspect a script bug. The only thing that could affect two http calls from two different scripts like that is not the script itself but something in between the sender script and the receiving website where the data is corrupted.
  3. Sorry I should have noted that the maxlength is far, far beyond the small number of characters where the truncation is happening. by default of course it's 2k and I'm never setting it to less than 2K, ever. I realize this is really a shot in the dark, I'm just so stuck, I really think it's not my code/server. But never say never, I know that all too well. I just wonder if anyone else has ever seen this happening, is it just me? And I should have noted that ALL the requests are coming from my own scripts so I know exactly what is going on, on both ends. The reqests are nothing special... and umpteen zillion of them work just fine with no errors until it glitches once in a blue moon. llHTTPRequest(URL, [HTTP_METHOD, "POST", HTTP_MIMETYPE, "application/x-www-form-urlencoded", HTTP_VERBOSE_THROTTLE, FALSE], postdata); Where URL is my web server where I'm logging the errors. Just for fun here's the full error report for a typical truncation error event. Note that the expected form value for this particular API should look something sorta like: "source=subscribers2&groupname=blahdeblah&mode=subscriber&owner_key=a30b48f3-ecc2-4004-b5a2-fc1f26ef344x" But it's chopping it off right at the beginning of "groupname". So it's a hard-coded parameter name... not any kind of variable... and all the rest of the params are just... gone. Then .07 seconds before this there was a very similar error but the point of truncation was different. The other APi came from a different script in a totally different region, too. So it's not some kind of region glitch. Nor is it a specific LL server glitch since the other POST came from a different server. But it could be some kind of gateway problem or something, I don't know... _____ Error count: 2 minutes since last error: 0.07685149 Base Exception: System.ArgumentNullException System.Web.HttpUnhandledException in Boolean HandleError(System.Exception) Exception of type 'System.Web.HttpUnhandledException' was thrown. HTTP code: 500 System.ArgumentNullException in Void StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean) Parameter name: String Form: source=subscribers2&g POST From: sim10637.agni.lindenlab.com X-SecondLife-Object-Name: Syndicate Sunday Designer Admin X-SecondLife-Object-Key: d20e5a72-5dcc-ebdc-70bf-3bbdd003a3b1 X-SecondLife-Owner-Name: Ylva Somebody X-SecondLife-Owner-Key: x30b48f3-ecc2-4004-b5a2-fc1f26ef3441 X-Secondlife-Shard: Production http://slurl.com/secondlife/Somewhere/167/22/2996
  4. I've been plagued by a very occasional problem for a very long time now (years?) where a few HTTP POST requests from in-world to my web server get truncated. So for example I make a normal HTTPrequest() POST request from a script to my web server with data like param1=bob&param2=fred and it arrives at the server truncated, for example I might get "param1=b" or "param1=bob&pa". These cause an error on the server because required parameters are missing, so they all get logged. These result in an error 499 returning to the script inworld. Since I typically have lots of http requests coming in, I'll get these in very small batches, maybe 2-3 over the course of just a few milliseconds, sometimes it might be the same API call and the location of the truncation in the post data appears to be pretty random. I might get two identical API calls a few ms apart that are truncated, but at different positions in the data. It isn't related to a particular API, it happens to all of them, but there are a few that get called far, far more than others so naturally the distribution is weighted toward those heavily called APIs. These are extremely occasional, maybe I'll get a batch of 1-3 all within a few milliseconds, a week apart, or two weeks or who knows. Considering I'm getting maybe 1 HTTP request per second (some GETs, mostly POSTs) from in world scripts, pretty much 24x7, over the course of a week that's a lot of perfectly fine requests until another little batch of truncated requests comes in. Has anyone else seen anything like this that's logging bad HTTP calls at the web server level? I just don't see any pattern to these mystery truncations. It's not a huge issue but it's been nagging me for ages and I just wonder what is going on. I'm convinced it's some kind of LL server glitch and they are being sent truncated. I've never seen this happen to any HTTP requests other than from an inworld LSL script. I really don't think it's an issue with my web server (Azure web app), but hey you never know. But I heavily suspect they are being sent truncated.
  5. OK I think I have a good handle on how this affects me and my various systems and scripts. But I have one super vital question: will search in the viewer work with retired (historical) names? Will it find the correct avatar, even with their old names? Same question for https://search.secondlife.com/ but that is much less important to me.
  6. Yeah thanks! BTW for those interested I found this very helpful to understand the confusing name situation on various SL properties: http://wiki.secondlife.com/wiki/Category:LSL_Avatar/Name
  7. This would be critical functionality to impement. They HAVE to do this. Up until this minute legacy names were guaranteed to never change and always be unique. So let's say you have a list of subscribers to a list. Instead of exporting a list of UUIDs, you could export a list of legacy (or account!) names and be safe in the assumption that those were always useable, meaning, you could re-import them and in some way or another convert them to unique UUIDs. Now if that assumption is broken that is really going to screw up a lot of people that happen to have lists of avatars for whatever reason (sales logs, committee memebers, whatever) that are now broken. If you re-import them and half of them are completely unknown because the avatar changed their name... what a mess. Big problem. The only reasonable thing to do and not break a zillion tools and external lists that make those (previously perfectly safe) assumptions that legacy names will always be tied 1-to-1 to a UUID is to make ALL names, historical + current, be searchable/convertable to a unique UUID. Anything less will really screw over a lot of people.
  8. When you say "always use UUID values", yeah that's true when storing a list of avatars in some way. A database of legacy or account names only is indeed useless which I think is what you are getting at. For most APIs you need UUIDs so that's nothing new. For messages and whatnot to end-users, obvious I need to use something friendlier than a UUID, display names are useless as they can change on a whim, so I need to understand the details behind legacy names (and accout names, if they are changing too?) As a scripter I'll definitely need more specifics than general guidelines. Exactly how will the APIs change? Exactly how will llKey2Name() change? Under what conditions does it return a different name for the same UUID? What about llGetObjectDetails? What about llGetUsername? Will user names remain the same and never change or will they follow legacy name changes? Will legacy names still be called legacy names or will there be new terminology? llRequestAgentData? What about llDetectedName()? What about names passed into listen events? llSensor()? AGENT_BY_LEGACY_NAME? What about the q parameter for search.secondlife.com/web/search/? What about the q parameter for search.secondlife.com/client_search.php?s=people ? How will the results returned by those URLs change? What about the names shown for an avatar's web profile i.e. http://world.secondlife.com/resident/c3cf4c84-c31b-47ac-855c-3858375e0360 ? Do I need to store multiple names for every avatar UUID now? Will there be an API to get all (current + historical) legacy names from an avatar UUID? Or will all APIs like llKey2Name and llRequestAgentData only return one legacy name, the latest one? Can I look up a UUID from an old legacy name after it has been replaced? As you can see there are a lot of details that need to be known for scripters to fully understand what to do. I'm looking forward to the gory details.
  9. Just wondering if any detailed information exists yet on LSL API changes related to the upcoming avatar name changes. If not, where and when can we expect some details? I'm really hoping there are no breaking changes, but I need to know what is going to happen specifically to the APIs and any changed assumptions about avatar names before any changes roll out so I can get any necessary updates to my products out there.
  10. Yep that sounds like the best bet, thanks, just wanted to make sure I wasn't missing something about getting that retry header
  11. @Oz Linden one followup, how can I get the Retry-After header in the 503 response? The request is coming from an in-world script... llGetHttpHeader() in an http_response event doesn't work. I can't seem to get any of the usual expected response headers that way.
  12. I love how the second assumption in that bug report is that it's an evil conspiracy, lol.
  13. In my case the remote object sends a small request to my inworld server, then server replies with an "ok" response, then immediately makes an HTTP request back to the remote with some data. The only reason it does that instead of just sending the data back in the response is due to the response size limits. Sometimes the data can be a largeish payload so it has to turn around and make a fresh http request. Maybe a little pause between the response and the following request back would do the trick... but the actual number of responses + requests to the remote is just 2 or 3, there's no barrage of requests. Unless the quota somehow factors in the payload size. And in one case (and probably the second) where this happened the remote region was heavily populated and lagged, so it was probably an issue with other scripts in the remote region gobbling up all the quota... so that makes sense. Changing this quota to "same owner" would be great. At least I can watch for a 503 and the Retry-After header and know when it's hit. Thank you all for the info, that was very helpful.
  14. I am extremely familiar with all those limits and have delt with just about every single one (sometimes painfully, lol) at some point or another, but I'm asking specifically about the error I posted about. None of the documentation addresses what that error might actually mean. Any idea?
  15. Anyone have any clue at all what this error message might mean? "Cap invocation rate exceeded:" followed by a mysterious UUID. I'm seeing this from some HTTP based inworld servers that are getting a non-excessive number of requests. Some background... no, it's not http rate limiting, I detect and handle that. The servers in question have been stress tested to limits far above what they are at now (an order of magnitude larger) without ever seeing that message. I've seen it only once before, coming from an inworld server connected to a kiosk in an extremely laggy region (a very busy fashion store). The error came from the non-lagged server in a different region, not the lagged kiosk. I am wondering if the lag is causing the kiosk to be unresponsive to the server in some way... causing that error. What's weird is that it is most definitely not http rate limiting. We're talking a handful of http requests per minute. My guess is that the server is making an http request to the kiosk in the ultra lagged area and it gets that error. In this most recent case the server got a 503 error, so it looks like it's possibly an http request to an object in a laggy area. I can't find a darn thing about this error and it's extremely sporadic. It happens once... then never again. But now it's cropping up again on some very important servers and I need to get this resolved asap.
×
×
  • Create New...