Jump to content

Sasun Steinbeck

  • Content Count

  • Joined

  • Last visited

Everything posted by Sasun Steinbeck

  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.
  16. Update: I tried a commercial long looped dance animation in my own object/script and it stopped immediately on llStopAnimation! So it must have been something with that other animation?I have no idea. Why would one animation stop and another refuse? Maybe this is not a real problem and most animations don't ignore llStopAnimation like that, I have no idea.
  17. Hm I just tested out a commercial dance ball in my inventory with a long looped dance. As soon as I jump off, the dance stops! The script must be stopping my looped dance. How??? It doesn't appear to be animating me with anything else.. the looped dance just stops immediately. What's the trick?
  18. Thanks much for the tips. I downloaded the bvh files, uploaded "avatar_stand" unlooped (yes it's a single frame) twice, once at pri 0 and once at pri 4. Neither one stopped the currently looping animation. The high priority one overrode it, but as soon as it ended, the dance resumed (which makes sense, since it was merely tempoarily "hidden" by the short high priority stand animation). So no luck so far at all. Contrary to what the documentation says, there appears to be NO way to really stop a looping animation immediately, period. You can only "hide" it temporarily with a high priority animation. I haven't tried that yet but a high-priority "stand" animation may be more confusing to the dancer than just letting the current loop finish. Plus I have no idea how long to play the "hider" animation since I don't know how long the current loop is going to take to finish. If anyone has any other ideas I'd love to hear. Or is this truly impossible? The only thing that actualy seems to work is the system Avatar/Avatar Health/Stop Avatar Animations in Firestorm (not sure if that's in the standard viewer). But this can't be done via script.
  19. I am trying to stop a looped animation immediately. Sample code below. From what I read the trick is this: "If the animation to be stopped is the only playing animation (as found via llGetAnimationList), it will continue to play to its end (if looped it will continue indefinitely). If you must stop a looped animation, playing a single frame non-looped one immediately after stopping it, at low priority, will clear the list." I'm testing with the only full perm looped animation I have, the ever popular "Chicken Dance (looped)" animation. The trick above is just not working, or, the "single frame non-looped" animations I'm trying are not the right kind. I was hoping that llStartAnimation("stand") or one of the built-in anims would immediately stop the dance loop, but nothing will stop it, for me or anyone else. Drop the script in a prim and click to start, again to (in theory) stop. What am I doing wrong? I have some other freebie single frame looped animations, and when I start one of those, chicken dance immediately stops and the new one starts. However if I try triggering then stopping that one (in place of "stand") then chicken dance resumes and finishes the current loop, then stops. Does anyone have this magical single frame non-looped animation I can have? I was really hoping one of the system anims would do the job since there is a big problem including any additional animation in the inventory of the product I'm building. I'd be glad to send you a test prim with this dance installed so you can fiddle with it. string curAnimation; getPerms(key id) { if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) { llStartAnimation(curAnimation); } else llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION); } default { run_time_permissions(integer perm) { if (PERMISSION_TRIGGER_ANIMATION & perm) { llStartAnimation(curAnimation); } } touch_start(integer total_number) { if (curAnimation != "") { llOwnerSay("stopping: " + curAnimation); llStopAnimation(curAnimation); llStartAnimation("stand"); curAnimation = ""; return; } curAnimation = "Chicken Dance (looped)"; getPerms(llDetectedKey(0)); } }
  20. I have 1.2 million names/keys in my database. Let's say for the sake of argument you are correct, that 99.9% of them will be easily found on the first page. You are probably right. So let's see, 1,200,00 * .001 is... 1,200. Yes, 1200 names, if that percentage guess is realistic, will not be found. Is that number acceptable to me? Maybe for you, but not for people that work with databases at this scale. My point here is not your specific numbers, but that "almost always" or "99.9%" is probably just fine for someone searching a few thousand or a few hundred thousand names. But when you get into the millions, "almost" is just not good enough. I really do not have a good idea of what percentage won't be found on the first page. But I will tell you that I was very surprised at how easy it was to find a few. I didn't write a program to search my database, I just looked at RANDOM at a list of names and started doing a few manual searches. I tried searching for a few dozen, then found Tila, and also found Secondary a short time later. By manually searching. So I'd be very curious what the real numbers are on how many residents won't show up on the first page. I'm glad to hear that you tested so many names and had no problems finding them on the first page. That's good news. After finding those two names I was pretty darn worried. Maybe I just got extremely, incredibly lucky finding those two examples of why assuming that your search result will be on the first page is a bad idea. Maybe. I may take some time to run some tests like you did to really find out. But if it takes me the same amount of time to just fix my search code to loop through all the search page results, I'd rather just make that work - then my search results will be better in the end. I must reiterate that all of this pain would be completely irrelevant if we had a decent and authoritative API to call to do this, instead of the complicated, messy kludge that we have now.
  21. It's not "better", it's either do or die. As if we have a choice at this point, right? THAT'S what sucks, that we all had to scramble to fix this. I had to convert or some key products would have continued to be non-functional like they were when vwrsearch first went down. And I'm sure you wouldn't argue against pusing for a simpler, more reliable web service, right?
  22. Where did I say vwrserach is perfect? And what does vwrsearch throttling have to do with the current discussion? Nobody in their right mind would assume that any LL service is perfect, lol. The fact that the old search isn't, and never was perfect, and that the new one isn't either, just proves my point that we DO NEED a reliable name2key service that doesn't make SL developers jump through hoops to parse the search results and returns useful error information.
  23. Yes, she does exist: https://my.secondlife.com/tula/#about_tab. Her legacy name is "Tula Resident". Your response proves my point exactly. If you don't know exactly how to parse the search results, you'll get bad data, as in "this person doesn't exist". Secondary Resident, however, does not exist. But you won't know that until you parse over 160 search results scattered over 20+ pages that you have to load. See what I'm saying? It's a mess! Do you have any authoritative information on exactly how search results are sorted? Can you share that information please? Don't assume that SL products can just assume that every name given to them to check is valid, current, and an existing avatar. I regularly get huge lists in the tens of thousands of avatar legacy names to import into my system, and almost always there is a good 5-10% accounts that no longer exist, are incorrectly capitalized, or just plain spelled wrong via manual copy and paste errors. If one of those lists includes the former Secondary Resident, I have no choice but to parse through that entire mess to figure out that that avatar doesn't actually exist. With any luck I'll get the actual avatar not on page 200 but on page 2, but I can't really count on that, can I? I have to keep parsing until 1) I find the verified name or 2) get to the end of the search results. So I must always be prepared to parse an unknown number of pages.
  24. Here's a good example. Let's say you're searching for an avatar with a legacy name of "Tula Resident". If you search on the account name, that is simply "tula" (parens are not part of an SL account name nor are parens always returned around account names in search results). So if you do http://search.secondlife.com/client_search.php?s=People&q=tula You'll notice that the first search result is not the correct avatar, so gotcha #1 is that you MUST search the entire result set. In fact, this search returns multiple pages! And the correct avatar with account name = tula is not even on the first page, so your web application needs to keep loading and parsing an undefined number of pages looking to confirm your search results. God forbid you search for an actual resident with an account name of "secondary" because you'll get 8 PAGES of search results, for every person with that word anywhere in their profile. This is simply not useable for real products that need to do a definitive name to key lookup without putting unnecessary and completely useless strain on the search servers, not to mention how tricky it is to do it right, which translates to lots of product bugs as you figure out all the crazy weird gotchas involved in search.secondlife.com (trust me, ugh) or incorrect keys. Someone testing this may never notice that it's possible to get multiple names in a search result, not to mention multiple PAGES, if every test name you ever test with only ever returns one search result. That's a bad assumption that I could easily see someone making, and now you've populating a database with BAD data, which is the worst possible situation.
  25. This turned out to be more complicated than I thought. If the returned avatar has a legacy last name of "Resident", then the account name is just a single word, so you need to distinguish account names that do and do no have a "." in them. For example Joe Resident with a username of "JOE" will return "JOE (Joe)", but an avatar Joe Bloe with username of "JOE" will return "JOE (Joe.Bloe)". Good luck to you guys trying to parse this mess, jeez.
  • Create New...