Jump to content
Sign in to follow this  
Caleb Linden

Deploy for the week of 2015-02-02

Recommended Posts

Second Life Server (main channel)

The main channel is getting the server maintenance project, which was previously on all RC channels

Scheduled Tuesday 2015-02-03 03:00-09:00 PDT


Second Life RC BlueSteel:

No Roll

Second Life RC LeTigre:

No Roll

Second Life RC Magnum:
No Roll
 

We will be monitoring this thread as the code gets released, so feel free to note any observations you have about the server updates.  If you have a specific bug you'd like to report, please file a Jira.

Share this post


Link to post
Share on other sites

Severe issue at Nuggy (http://maps.secondlife.com/secondlife/Nuggy/10/102/22) after today's restarts: when logging in there (which is where my home is) most objects do not load, nor mesh outfits and system clothes, neighbouring sims seem to be offline and cannot teleport out of there. But if I login at another region and teleport to Nuggy, everything seems to be fine. Also, logging in there is only achieved at the 3rd attempt most of the times. Any ideas, Caleb? Thanks.

EDIT: to my request, Support restarted the region once more and the issue seems to have been fixed — will post here further notice if the problem happens again.

Share this post


Link to post
Share on other sites


Caleb Linden wrote:

Hi Damian,

What kind of problem is your friend experiencing?

And is it persisting after a region restart?

 

Thanks,

Caleb

Hi Caleb,

 

Is fixed now. I asume sim restar fix the problem. But, for the record, in both regions issue began yesterday when Main Channel rolling maintenance. Inventory won't load, avatars was invisible, disconnect at Teleport to another region, contact list won load (viewer logs show timeout with server or connection issues).

But, with new restart all is workin fine now.

Thanks!

SaludOS/2

 

Share this post


Link to post
Share on other sites

What Damian Zhaoying reported is similar to what I experienced at Nuggy. It seems that after the rolling restarts the links to the grid for some regions weren't properly re-established.

I don't think it has anything to do with the new code added, since it only happened for some regions.

Share this post


Link to post
Share on other sites

Those symptoms sound like the region came back up with broken caps.

This problem with regions coming back online with total caps fail happens to a fair number of regions after the Tuesday/Wednesday rolling restarts & this problem has been happening for a long time.

Restarting the region again manually always seems to fix it.

I have no idea if the caps breakage is caused by the way the regions are restarted when its a LL rolling restart or whether it is just because a large number of regins are restarted at the same time. I have never seen a region come back online with broken caps after a manual restart but the chance of that happening is probably very minimal.

 

Share this post


Link to post
Share on other sites

More detail which may be helpful:

This probblem has been happening for at least a year - probably longer.

If there has been a rolling restart that day, we often see users in Firestorm support group, on the forums and on both the LL JIRA and Firestorm JIRA complaining of the same set of symptoms, which include:

  • Getting disconnected when trying to TP out of the affected region
  • All mesh failing to load.
  • Friends list showing all names as "loading..." and groups list totally empty.
  • Inability to initiate any IMs.
  • Avatar textures all grey.
  • Pacel information failing to load (in World -> About land)
  • Voice failing to connect
  • Anything that uses a capability to work is broken

TPing into the affected region and looking at viewer logs and dumping capabilities to debug console shows only one cap dumped - the seed capability. All other caps are failing.

These symptoms will be seen by all avatars on the affected region independant of viewer used.

Restarting the affected region will fix it.

Share this post


Link to post
Share on other sites

I asked about this problem when it started to happen much more frequently at one of the Simulator user groups. I found that transcript and it was from 2013.09.24. So this is roughly the date that the problem started to happen with much more frequency.

Ref: http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2013.09.24

See timestamp [12:22] onwards.

Share this post


Link to post
Share on other sites


Caleb Linden wrote:

Hi Damian,

What kind of problem is your friend experiencing?

And is it persisting after a region restart?

 

Thanks,

Caleb

2015-02-04T05:15:42Z INFO("WindlightCaps"): LLEnvironmentRequest::initiate: Deferring windlight settings request until we've got region caps

2015-02-04T05:15:42Z INFO: sendToSim: Sending throttle settings, total BW 3000

2015-02-04T05:15:42Z INFO: updateGeometry: WL Skydome strips in 1 batches.

2015-02-04T05:15:42Z INFO: updateGeometry: completed in 0.00seconds

2015-02-04T05:15:42Z INFO: LLViewerTextureList::updateImages: Flushing upon teleport.

2015-02-04T05:15:42Z WARNING: getCapability: getCapability(SimulatorFeatures) called before caps received

2015-02-04T05:15:42Z WARNING: getCapability: getCapability(GetMesh) called before caps received

2015-02-04T05:15:42Z WARNING: getCapability: getCapability(GetMesh2) called before caps received

 

As I said, restart sim fix the problem. All symptoms was same as reported by Whirly. (My bad when I said connection issues, was capabilities issues).

 

SaludOS/2

Share this post


Link to post
Share on other sites

I've been seeing the disconnect-on-TP problem for what seems like a long time, certainly since the CDN went active. Would sim-crossing failures be related? There's been a tendency for people to say to me "It's your connection!", and the possible coincidence of CDN did have me checking with my ISP, but they were not slowing down data packets from CDN nodes. There used to be a lot of warnings about the bad effects of UDP and TCP/IP running in parallel.

In the end I gave up on trying to figure it out. Nothing in my control seemed to be misbehaving, yet other people would always blame my systems, not their own. I can appreciate the temptation: I see the mirror of that, and it always looks like your fault.

I'm not sure what "capabilities" means, but there's enough similarity in the problems that I wonder if we have all been buried in a large and stinking pile of red herrings.

Share this post


Link to post
Share on other sites


WolfBaginski Bearsfoot wrote:

I've been seeing the disconnect-on-TP problem for what seems like a long time, certainly since the CDN went active. Would sim-crossing failures be related? There's been a tendency for people to say to me "It's your connection!", and the possible coincidence of CDN did have me checking with my ISP, but they were not slowing down data packets from CDN nodes. There used to be a lot of warnings about the bad effects of UDP and TCP/IP running in parallel.

In the end I gave up on trying to figure it out. Nothing in my control seemed to be misbehaving, yet other people would always blame my systems, not their own. I can appreciate the temptation: I see the mirror of that, and it always looks like your fault.

I'm not sure what "capabilities" means, but there's enough similarity in the problems that I wonder if we have all been buried in a large and stinking pile of red herrings.

1) You've been mentioning frequent sim-crossing issues for years.

2) UDP and TCP/IP have also been running parallel for years (i.e. HTTP textures and inventory.)

3.) And yet, not everybody has the same problems. In fact what seems like the lion's share of problems on this particular forum are brought up by the same handful of people, who are mostly in the UK.

Share this post


Link to post
Share on other sites


WolfBaginski Bearsfoot wrote:

I've been seeing the disconnect-on-TP problem for what seems like a long time, certainly since the CDN went active. Would sim-crossing failures be related? There's been a tendency for people to say to me "It's your connection!", and the possible coincidence of CDN did have me checking with my ISP, but they were not slowing down data packets from CDN nodes. There used to be a lot of warnings about the bad effects of UDP and TCP/IP running in parallel.

In the end I gave up on trying to figure it out. Nothing in my control seemed to be misbehaving, yet other people would always blame my systems, not their own. I can appreciate the temptation: I see the mirror of that, and it always looks like your fault.

I'm not sure what "capabilities" means, but there's enough similarity in the problems that I wonder if we have all been buried in a large and stinking pile of red herrings.

If a region has total capabilities fail, EVERYONE will suffer those same symptoms on that region, including disconnect when trying to teleport out of it.

If you have been suffering frequent disconnects on TP for a long time and others do not get disconnected when TPing out of the same region at the same time then it is almost certainly to be caused by some problem at your end - connection or Firewall setting or router setting or a DNS problem.

You can find some info on what Capabilities are on these wiki pages, though they are a bit outdated now:

To see the full list of granted capabilties for the region you are on, open your viewer log file for that session (secondlife.log) and go to Develop (top menu bar, use CTRL+ALT+Q if you dont see Develop) -> Consoles -> Capabilities info to debug console.

Then check in your Secondlife.log and you will see a long list of capabilities like THIS

When a region comes back online with caps fail after a rolling restart, usually only one capability is dumped to log and you will see something like this:

INFO: newview/llviewerregion.cpp(2042) : LLViewerRegion::logActiveCapabilities: Seed URL is https://sim8860:12043/cap/e81b242b-06dd-de06-7b6d-2bb73c1d6853INFO: newview/llviewerregion.cpp(2045) : LLViewerRegion::logActiveCapabilities: Dumped 1 entries.

 Your log will also be full of warnings about failed capabilities, like this:

WARNING: newview/llmeshrepository.cpp(1120) : LLMeshRepoThread::constructUrl: ONCE: Current region does not have GetMesh capability! Cannot load 03148fe8-bd03-8b29-0a11-5b5ebd38c063.mesh

 

Just to note though, if a user has a certain kind of DNS problem (which is a problem at their end) they will see pretty much the same symptoms as when the region has capabilities fail but only they will have those symptoms and they will usually have them on every single region.

Share this post


Link to post
Share on other sites

Thanks for the info.

I'm not totally helpless at such things, but it's still pretty intimidating.

If it's possible to log these "capabilities", maybe it wouldn't be so hard for a viewer to give a warning. Though. looking at the Wiki pages, it looks as though that thought is very wrong.

I hope the Lindens have access to more recent documentation.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...