Jump to content

Deploys for the week of 2012-08-20


Oskar Linden
 Share

You are about to reply to a thread that has been inactive for 4252 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

 

Second Life Server (main channel)

The maint-server project from Magnum is being promoted this week. 


2012-08-21, 5:00am: Release Notes: 
https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12

  

Second Life RC BlueSteel

This channel will have the same maint-server with bug fixes.

  • Bug Fixes
    • VWR-5044Attachments only change/inherit the active group when they're "rezzed
    • VWR-25762: group owned objects appear as owned by (nobody) in Top Scripts and Top Colliders
    • VWR-20320: Show in search and set for sale remain enabled after owner changed
    • SVC-7760: Large object instant messages can corrupt returned object location URL making it impossible to determine the object's location.
    • STORM-1840: Searching legacy names in the "Choose Resident" floater with a period returns no result
    • SVC-7525: Selected objects move when a new keyframe motion is started
    • SVC-7793: Scripted agents can't abandon land on private estates
    • SVC-7917: Please automatically unmute avatars who have muted themselves, and prevent this from occuring server-side.
    • SVC-7968: When TPing using a landmark the server sends two TeleportStart packets
    • SCR-247: Scripts created by Residents who are limited to only the General maturity rating do not function as expected when inside an object that the scripter created that is running in a Moderate or Adult region
    • SCR-318llInsertString & llSubStringIndex support for 4 bytes characters broken since 12.02.06.248938
    • SCR-359: The http_request() event fails to trigger in child prims that do not use llHTTPResponse() after it has received 64 HTTP requests and will not trigger again even if the script is reset.
    • SVC-8124: Excessive "ParcelOverlay reliable" messages sent by regions since last rolling restart (2012-08-08)
    • SVC-8136: Attachment point pelvis not being released

2012-08-22, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/12

 

Second Life RC LeTigre

This will have the same bug fixes as are on BlueSteel.

2012-08-22, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/12

 

Second Life RC Magnum

This is a maint-server project.

  • Bug Fixes
    • SVC-7641: Object on land sending excessive messages. The messages sent from the simulator about objects now contain location information, making them easier to find and return.
    • SVC-8146: llRezAtRoot() does not set correct parameters (for sale) on rezzed object in Second Life RC BlueSteel 12.08.03.263047
    • SVC-7641: Add object location info to messages, was "Object on land sending excessive messages"
    • SVC-8124: Excessive "ParcelOverlay reliable" messages sent by regions since last rolling restart (2012-08-08)
    • SVC-8136: Attachment point pelvis not being released

 

2012-08-22, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/12

 

We will be monitoring this thread during the next week so please feel free to post issues that you feel have been introduced by the new code. Please file a JIRA for issues you find and post the JIRA link into this thread. It really helps us out. When determining if issues are relevant or not research is key. Tracking down exactly the right situation where an issue is occurring greatly speeds up the development process to get fixes in place.

I appreciate your help. Have a good week!

 

__Oskar

 

p.s. If you are interested in helping test SecondLife in beta please join the group "Second Life Beta" in-world. We also have an email list where we communicate upcoming projects and how you can help. (https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta ) Once a week we meet on ADITI to discuss new features, new bugs, new fixes, and other fun stuff. You are more than welcome. Information is here:https://wiki.secondlife.com/wiki/Server_Beta_User_Group

 

Link to comment
Share on other sites

My apologies if Ive missed it, but I dont htink I see anything in here to address the excessive Bandwidth usage / log spam problem(s).   I had thought something was supposed to be released this week to fix those?   (And afik they are grid wide; at the very least they are happening on main channel sims without pathfinding, and afik elsewhere as well, ie Blake Sea generally).

Link to comment
Share on other sites

I'm being told that LL does not hardware ban people? I'm and sick and tired of these greifers crashing sims, etc. all the time.  If there is no way to permantley ban someone then why is their even a AR system?  I'm serious, do I have to get an attorney to get a severe greifer taken off here. Blocking them from their ISP?

Link to comment
Share on other sites

That's the hope.

If feels like a dreadfully long time, but some oddities I've seen before this week's roll-outs, instead of the message spewing I'd expect, make me wonder if the network-admin people have done something temporary to reduce the effects. If so, nobody has said anything, and I hope the oddities haven't triggered JIRA reports which get closed with inadequate explanation.

Sometimes the Lindens do things that walk like a duck, quack like a duck, and weigh the same as a duck. And when they don't say anything the results are predictable.

Link to comment
Share on other sites

Hope...Yeah there's always Hope....

One thing still rankles: all through this issue there has been no comment made by Linden Lab on the subject, other than the second-hand reporting by Nalates Urriah.  Notation indicating that a "fix" is "pending" on the JIRA does not, in my book constitute adequate communication.  The Beta User Group minutes relevant to this issue have STILL not been published, and Oskar's post almost suggests that the SVC-8124 fix was added to the RC code as an afterthought.

I'm not comfortable in any way with the way that this has been handled by the management of Linden Lab, but according to some that is because I live in a nanny state and am apparently part of the "entitlement generation".

So if this is fixed, do we all wander off mumbling?  Don't get me wrong, I hope it IS fixed.

Link to comment
Share on other sites

Yeah, I guess my concern is the multiple flavours of spam just make me wonder if theres a single root cause, or not.

IF (and are we sure of this?) it all started at the same time, maybe.   But I know tha in particular I have seen the recurrent region connect / dsconnect & related messages quite often going back a long time.

What Im afraid of, but of course have no evidence, is that there are multiple underlying causes of the spam; that they had something to somehow suppress the spam and that got broken recently.

Also, Im not sure that the spam is sufficient to explain all of the BW spike - can someone do the maths, please?

Not sure if simply suppressing the spam is thw best answer as opposed to making aure its not generated in the first place.   Presumably a lot of other things are happening when a spam msg is generated - the spam is just a report of something not the thing itself.

At the end of the day though well beat our brains out tryig to second guess this ... really we have little choice but to sit back and see what happens.   Or leave for other places that work better, if there are any.

Link to comment
Share on other sites

Ayesha, you give every impression of being one that feels they are entitled to have Linden programmers explaining things to your idea of acceptable communication. I tend to think a reasonable person would have figured out the programmers are busy programming and will only ever give communication a secondary priority.

Whether you live in a nanny state or not is moot. Your continuing critique of what the Lab should do seems to reveal a desire to have the Lindens take care of you to the standards you want... nannies take care of people. So, I see that as a desire for a nanny state of being on your part.

 

I seldom get any special information from the Lab. The information I report is available to anyone. The Lab has NOT made it easy to find, but a huge majority just don't care. So, the effort at communication is probably in balance with the interest of users.

This update thread on Deploys is handy. But, one can know what has happened and what is likely to happen next week by attending Friday's Server/Scripting meeting. That takes an hour a week. Or one can read my blog. But, you get the news when I get around to writing it up.

I've been running a network monitor the last few days and preparing to see if SVC-8124 in Magnum makes a difference. While several people I trust to avoid Chicken-Little-reactions tell me it is a significant problem, I had to go looking for it. I live near the SW corner of a region. I haven't seen the HUGE problem in the regions I've explored except in the Viewer Statistics. My monitor shows only about 12% of what the stats panel is showing. Searching I have found a couple of places where the Viewer Stats show bandwidth spiking but the monitor shows a much smaller increase.

Checking in regions in the Magnum area is hard to do. Figuring out where they are, other than the sandboxes, is tedious. Later today I'll be crusing through those again later today and tomorrow.

Link to comment
Share on other sites

Wrong, Nalates, just plain wrong.

I do expect managers to communicate, not programmers.  As to being "entitled", I do consider myself entitled to have SOMEONE at Linden Lab explain their recent lack of openness - so do a great many others!

Indeed, the information you disseminate is effectively available to anyone, provided their RL activities permit it.  Believe it or not I am very glad you do write those things up in your Blog.

The bandwidth issue has been complicated by the comparison of Bits and Bytes, and the 12% figure your monitor sees is exactly what would be expected if the viewer sees bits (kilobits or Megabits) and your monitor sees Bytes! As I understand matters one Byte is equivalent to 8 bits.

But I do assure you...the Bandwidth issue does not solely reside on Magnum, or any of the RCs.  A brief sortie down to Nautilus has confirmed that to me.  "ParcelOverlay Reliable" may have been tamed, but the other spam messages are still there, live and kicking on Main Server sims. (And Yes, I did check corner sims as well).

And, for the record, I do not favour a "nanny" state, but I do favour one that does not take a "devil take the hindmost" attitude.  But thereby we'd be getting into politics, and politics do not cross the Altlantic well.

 

Link to comment
Share on other sites

First off what time is the meeting? Where are we notified? Most of these things are not available to Europeans.


2nd you give the impression that Linden Labs only have programmers working for them. That in itself is wrong. It is not at all unreasonable to expect a company you pay money to every month to tell you what is going on. They actually employ people to do this. GOOD CUSTOMER SERVICE has nothing whatsoever to do with being in this  nanny state. It is every customer's right to expect a company to communicate when there is a problem. And it says it all that the information is tucked away and hard to find. It should be right here - where we can all see it.

Perhaps a link to help those of us who can't be bothereed to go looking - or should that be don't know where to start and actually have other things to do with our time than waste trying to find it.

Link to comment
Share on other sites


Nalates Urriah wrote:

I've been running a
network monitor
the last few days and preparing to see if 
 in Magnum makes a difference. While several people I trust to avoid Chicken-Little-reactions tell me it is a significant problem, I had to go looking for it. I live near the SW corner of a region. I haven't seen the HUGE problem in the regions I've explored except in the Viewer Statistics. My monitor shows only about 12% of what the stats panel is showing. Searching I have found a couple of places where the Viewer Stats show bandwidth spiking but the monitor shows a much smaller increase.

Natales, sounds like you're using a monitor that reads in kiloBYTES per second and the statistics bar reads in kiloBITS per second, so your monitor should give you a reading exactly 1/8 of the statistics bar, or 12.5%. The important issue is that the bandwidth draw in the effected areas is a good five times what it would be normally and you're probably not going to notice if you're not looking for it.


Nalates Urriah wrote:

I seldom get any special information from the Lab. The information I report is available to anyone. The Lab has NOT made it easy to find, but a huge majority just don't care. So, the effort at communication is probably in balance with the interest of users.

That's certainly an interesting conclusion. However, I imagine anyone using a bandwidth-metered account WOULD care that they could be using five times the bandwidth they were expecting to use.

Some of my posts on this topic may sound like I'm part of the "prosecution." I don't see it that way - I think of myself as an "expert witness" who is trying to determine exactly what is going on. I'm actually more likely to defend Linden Labs against the charges of forum posters than pile onto them and I'll decline to give my impression of certain posters on this topic because using the words "drama queen" very seldom advance a discussion.

However, I find Linden Lab is consistently poor at explaining technical issues and changes. It's not necessarily the job of the programmers but it should be the job of SOMEBODY.  And it is Just. Not. Done. I'm reminded of how Viewer 3.2 with the new interface was rolled out on a Tuesday night as an automatic update with no notice and before the tutorials were even up. The new interface wasn't even mentioned in the release notes if I remember right.

Nannies don't take care of children because they love them; they do it because somebody is paying them to do it. If someone pays a nanny to take care of their child and comes home to find the child locked in a closet with a bag of Oreos while the nanny settled down for an afternoon of Wii action they are probably going to be upset. People are paying Linden Lab to provide a service. When you contract for a service you generally would like it to be done to, well, the standards you want. Quietly accepting the level of service you're given is what you do in the fiberglass chairs at the Department of Motor Vehicles.

 

 

Link to comment
Share on other sites


Cully Andel wrote:

one question. Has the problem been solved? Because if it should have been, it doens't look like it has been.

Cully, the fix was distributed the way server updates normally are - it is currently on about 30% of the grid and assuming no major problems happen it will be on the entire grid next Tuesday.

Link to comment
Share on other sites


Nalates Urriah wrote:

Ayesha, you give every impression of being one that feels they are entitled to have Linden programmers explaining things to your idea of acceptable communication. I tend to think a reasonable person would have figured out the programmers are busy programming and will only ever give communication a secondary priority.


So you think it is unreasonable for how many SIM owners times $300 a month should ask for a LITTLE BIT of communication from the Lab?  That makes them unreasonable?

Surely there must be at least one programer at the Lab able to translate Geek Speak into simple English?

I don't think we are expecting a ten page explanation of things.  Just enough so we can get about enjoying our Second Lives and for people like me who spend a lot of time In World helping others, enough information so I can do so in a timely and well informed manner.

 

Link to comment
Share on other sites

I just wanted to say Today's Roll went much smoother than last week's LeTigre Roll. Where last week the sim was sputtering and having issues connecting with it's neighbors for nearly an hour, today with in 5 seconds it was running beautifully and nary a hitch. Not sure if you did anything different, but if you did, it worked.

Nice Job.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4252 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...