temp-on-rez sometimes isn't temporary when rezzed?

Maybe I've just led a charmed existence, but I've never seen this before this evening, when the database was "having issues": a temporary object in a scripted object's inventory, rezzed on touch by llRezObject(), rezzed as non-temporary. The script actually rezzes two copies of the object in different locations: one rezzed as temp, the other not. Later, when the db was back to normal, the objects would both rez as temp, as expected.

Now, I've seen lots of stranded "bullets" around, and always just assumed that the weapon was using faulty ammo, but now I wonder: Does this temporarily non-temp problem happen often? Does one need to put in an llDie() timer to make sure objects that are supposed to be temporary actually go away eventually?

(Honestly, I've rezzed a lot of temp objects in the past without any such timer and never seen this before.)

They've been dinking with the temp-on-rez stuff in an effort to reduce load on the asset server.

Yes, for some strange reason, temp-on-rez objects somehow still hit the asset server, so it is one of the major contributors to its ongoing issues.

They have been working on a way to make ToR objects truly "temporary", and it was noted by Andrew Linden at his office hours last week. Perhaps with the asset server acting weird, you were seeing the effects of a new related anomaly.

Seems like a good idea, since a LARGE percentage of the population uses temp re-rezzers to have condoes with more than 4 prims, and anybody griefing sims uses temp to continue to load the servers after the regions fill up, I could see how tracking all those assets could be burdonsome.

I produce a range of balloon rezzing devices which produce physics-enabled, non-phantom, temp-on-rez balloons. I have never experienced any issues with temp-on-rez, nor have I ever received any reports from the several hundred users of these items.

For what it's worth, the rezzing object contains objects that are pre-edited as temp-on-rez, although as a belt and braces (mainly to guard against my own inattention when editing the balloon object) the objects also contain: llSetPrimitiveParams([PRIM_TEMP_ON_REZ, TRUE]) in the on_rez event. I have literally rezzed tens of thousands of these balloons without any issues.

Are you sure some script event isn't removing, or failing to set, the temp-on-rez property?

Thanks for the replies. To answer Pale: This particular thing has been working for months, and works now, but it failed (twice) during an asset server / database incident. It's not a typical temp-rezzer in that it doesn't keep re-rezzing on a timer (I've made those, too, and they've always behaved just fine), it just rezzes on touch a half-dozen glorified poseballs, each of which were set temporary in the Editor before being put into the scripted object's Inventory. And the fun part of this particular glitch was that the script rezzes two copies of the very same Inventory object at different locations and rotations: only one of them failed to be temporary when rezzed. The script in the rezzed objects does not independently set (nor clear) the PRIM_TEMP_ON_REZ property--if this gets to be a regular occurrence, setting it again there could be worth a try: it would be a little cleaner than the alternative llDie-on-timer workaround.

Just now, while double-checking the scripts, I noticed what seems like another new behavior for temp objects, although my memory is a little fuzzy about this: Wasn't it the case that having a temp object selected in the editor kept it from being reclaimed while selected, just as sitting on it does? If so, that's changed, at least in this 1.22.2.89099 sim. (Sitting still works, though.)

It should be noted that Temporary On Rez was changed to just Temporary several years ago. I'll write up a JIRA to change the name to PRIM_TEMPORARY (with the old flag being retired from the syntax highlighter, they would have the same value and syntax, nothing would change, nothing would break if recompiled).

https://jira.secondlife.com/browse/VWR-7708

Back to the original query. This looks more like a strictly asset server issue that just happened to affect your temp on rez objects Qie. Somehow the system lost track of the temp nature of the items. I spend many more hours logged onto Aditi then MG and it's db system is much less robust the the MG system. You get to see many problems that aren't seen in the MG such as opening a script and it never (never until now that is) showing the text, saving a script and it never saving, rezzing objects that don't rez for several minutes and many more db problems. Being that it is Aditi, you get used to it and work around it.

All of these problems I have never encountered on the MG until the first part of this week. I am sure that others have noted that something is seriously wrong(more then usual) with the MG asset system right now. Monday night I was able to see the same problems that have always been a part of Aditi, including taking a very long time for text in a script to rez and some save failures. Hopefully this is all due to a bug in client>sim>asset system communications introduced in a recent update. In that case, it will be quickly resolved. If on the other hand, our present system just can not handle the concurrency, then I have no idea how long it is going to take to correct.

I am hoping it is the first scenario and not the latter. As many are aware, we are now past the capabilities of the llEmail system. Kelly is working furiously to introduce a new feature which will finally allow us to do http requests from outside SL. This will finally resolve the problems we have had for about 2 years with RL to SL communications involving xml-rpc, email and having to constantly http poll the outside from within SL. But if this asset system problem is not a bug, I haven't seen any mention of a similiar miracle cure for our woes.

I normally wouldn't even bother commenting on concurrency, having survived many milestones that were quite bothersome for awhile. We used to have serious problems with every new jump per 1000 online, which would provoke a furious bout of fixes for the system to keep up and then we would be back to normal until the next milestone. But starting at about 24K concurrency, there has been a slow, gradual degradation in performance instead.

Keeping my fingers and toes crossed and am just glad I'm not the one having to come up with the fix. My sympathies go out to Kelly and the rest of the grid/code/qa mechanics. No matter what else, you guys rock and I know for a fact that several of you don't put in just 40 hour work weeks!

Thanks, Jesse. Yeah, at least for now, I'm writing it off as an asset server glitch. At the time the problem arose, the main grid was showing many of those same Aditi-like symptoms (script text taking forever to load to the viewer, stuff rezzing late or not at all, etc.).

I guess trying to devise a workaround should this start happening regularly would be the proverbial rearranging of deck chairs, because most anything could go wrong under the failure conditions; that is, it's doubtful any workaround would function reliably either, under the conditions that trigger this failure. And a few stranded, not-quite-temp prims won't be high on our lists of things needing failsafe fixes, if this gets to be a common situation.

Thanks again, everyone, for the responses.