Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

1.5.7 lsl changes
Andrew Linden
Linden staff
Join date: 18 Nov 2002
Posts: 692
11-09-2004 17:24
1.5.7 will be released tomorrow.

The release notes have an item that may adversely affect some existing scripts so I thought I would make a special post here.

- Increased the sleep after an llGetNextEmail() from 1 to 5 seconds to
reduce the load on the database from scripts that constantly and
rapidly poll for incoming emails.

On the bright side, we have actually branched the 1.5.x family of the code base so we can start working on 1.6 which will have new features. I don't know where a fully functioning XMLRPC implementation fits into the schedule (1.6 or 1.7... dunno), but we definitely plan on getting it done eventually. We anticipate that it would take about a single developer about 1 whole month to get that working right (some of our system will require a rewrite) so we have't been able to fit that into the priority queue yet.
Adam Zaius
Deus
Join date: 9 Jan 2004
Posts: 1,483
11-09-2004 17:44
Hrrm, I cant but feel this may not be the best way of doing it, as far as I can see, this will only cause multithreading, but unlike ordinary multithreading, these scripts will have timers.

Although 5 secs is a bit of a strech from the 20 of llEmail? (with sim-controlled mail queue's is there any chance of getting this lowered? to say 10?)

-Adam
_____________________
Co-Founder / Lead Developer
GigasSecondServer
Rathe Underthorn
Registered User
Join date: 14 May 2003
Posts: 383
11-09-2004 18:01
If a full implementation of XML-RPC is going to take a month or longer, couldn't you hold off on the llGetNextEmail() delay until then? Getting data IN and OUT of Second Life is already frustrating enough. This is going to put a serious damper on some current projects. Not that overloading the servers is good either. But add this on top of the current outgoing delays, latency issues, and inefficent parsing functions in LSL and the round-trip time of any useful data makes it practically useless for any (near) real-time or interactive objects.

Sincerely Frustrated,
Rathe
Azelda Garcia
Azelda Garcia
Join date: 3 Nov 2003
Posts: 819
11-09-2004 18:11
Edited massively after realizing that multithreading for this is easier than I initially thought, to say simply:

Please can we receive notification of these types of patches significantly beforehand? Day before does not cut it. 2 months would be nice, could live with 4 weeks, at a push.

Azelda
_____________________
Mark Busch
DarkLife Developer
Join date: 8 Apr 2003
Posts: 442
11-09-2004 18:11
oooo 20 seconds of delay after llEmail??? that explains a lot...
is the delay per script, per object, or per owner?

thanks!!!
Zuzi Martinez
goth dachshund
Join date: 4 Sep 2004
Posts: 1,860
11-09-2004 18:18
really seems like email arriving should be an event like listen or timer or such. any reason it can't be?
Catherine Omega
Geometry Ninja
Join date: 10 Jan 2003
Posts: 2,053
11-09-2004 18:38
From: Mark Busch
oooo 20 seconds of delay after llEmail??? that explains a lot...
is the delay per script, per object, or per owner?

thanks!!!


Per script.
_____________________
Need scripting help? Visit the LSL Wiki!
Omega Point - Catherine Omega's Blog
Adam Zaius
Deus
Join date: 9 Jan 2004
Posts: 1,483
11-09-2004 19:15
From: Zuzi Martinez
really seems like email arriving should be an event like listen or timer or such. any reason it can't be?


Because Email works on a poll rather than a push, which is where this problem is arising. :)

-Adam
_____________________
Co-Founder / Lead Developer
GigasSecondServer
Francis Chung
This sentence no verb.
Join date: 22 Sep 2003
Posts: 918
11-09-2004 20:26
Ugh. Is there any way we can undo this? This will definately make some of my systems much less responsive.

While we're at it, can we remove the 20 second email delay? Pretty much everyone uses multiple scripts to get around that one too :P

And uhm.. Won't this break town hall repeaters?
_____________________
--
~If you lived here, you would be home by now~
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
11-09-2004 21:37
hmm while i find this annoying it doesn't throw too big of a monkey wrench in the system.

A while back i was advocating for an Instant Message protocal that would allow for objects to send instant messages (the message in this case would be a list) to other objects in different sims.

The basic idea was that the script would first register the prim as listening and the sims would then have to keep the registration active. Like how XML-RPC has been setup so that prims can cross sim bounderies but the data can still be accessed. The major advantage of this system is that it uses lists instead of strings. Allowing for easier data transfers between scripts. Easier data transfers mean less CPU time is wasted converting back and forth between strings and lists.

One way of handling the lag on the server would be to tie commands to Energy.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly

Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
Moleculor Satyr
Fireflies!
Join date: 5 Jan 2004
Posts: 2,650
11-09-2004 22:56
  1. Yeah. Ok. Uhrm... it took you about six months to get the idea of letting us know about LSL changes beforehand. It's good that you DID get the idea, and I'm not complaining about you telling us beforehand, but... Could you tell us a bit sooner than just twelve to twenty four hours prior to it? That's not much time to recode and release patches, which is the whole reason we asked to be told in the first place. Sure, it's better than no warning, but a mere half-day is like saying "Ha ha. We're about to completely fuck up every script you've ever made, and what's worse is you know it's coming and there's nothing you can do to stop it! Suckers!"
  2. You know, I'd just like to take this opportunity to say "I told you so" again. When you mentioned that you'd be doing a half-attempt at XML-RPC, and would get the full implimentation in on the next build, I warned you that it was going to end up taking months. I was right, wasn't I? Told ya so.
  3. The whole reason llGetNextEmail is hammering the server so hard is because there's no other way of getting info to an inworld object. If you'd simply give us Obj<->Obj communication, that'd solve some of the problem right there. XML-RPC would do the rest. Then again, XML-RPC is going to have Obj<->Obj communication in it anyway, so ya might as well focus on that I guess.
_____________________
</sarcasm>
Azelda Garcia
Azelda Garcia
Join date: 3 Nov 2003
Posts: 819
11-10-2004 00:01
> Because Email works on a poll rather than a push, which is where this problem is arising.

Actually, I think its because the email server has no clue which sim your object is in, so it just waits for your object to ask it.

Theres no fundamental reason why they couldnt configure .forward or similar to send the message directly to your object, just like they do for xmlrpc.

Of course, in this case they'd ideally need to implement handoffs between servers so you wouldnt lose message after a border crossing.

Azelda
_____________________
Andrew Linden
Linden staff
Join date: 18 Nov 2002
Posts: 692
11-10-2004 10:19
Sorry for the short warning. That change was made yesterday.

One thing I didn't mention yetsterday (becauase I didn't know then) was that this change is a temporary fix until we get the new database hardware up. This means that the soonest (and most likely) date that llGetNextEmail() will have a lower inherent delay will be in 1.5.8 which is about two weeks away.
Adam Zaius
Deus
Join date: 9 Jan 2004
Posts: 1,483
11-10-2004 11:04
From: Azelda Garcia
> Because Email works on a poll rather than a push, which is where this problem is arising.

Actually, I think its because the email server has no clue which sim your object is in, so it just waits for your object to ask it.

Theres no fundamental reason why they couldnt configure .forward or similar to send the message directly to your object, just like they do for xmlrpc.

Of course, in this case they'd ideally need to implement handoffs between servers so you wouldnt lose message after a border crossing.

Azelda


I know, this one poses a problem. I'd even settle for having [email]UUID@simXYZ.agni.lindenlab.com[/email] if we could have it pushed into the script automagically via the email event (llGetSimulatorHostname() seems perfect for this?). Although, I agree with you - there shouldnt be any reason why you cannot create a routing table that updates whenever a script with an email() event in it, is loaded in a sim.

-Adam
_____________________
Co-Founder / Lead Developer
GigasSecondServer
Raphael Rutherford
Resident Resident
Join date: 26 Mar 2004
Posts: 236
11-10-2004 12:40
From: Andrew Linden
Sorry for the short warning. That change was made yesterday.

One thing I didn't mention yetsterday (becauase I didn't know then) was that this change is a temporary fix until we get the new database hardware up. This means that the soonest (and most likely) date that llGetNextEmail() will have a lower inherent delay will be in 1.5.8 which is about two weeks away.


This is great, except for the fact that this unannounced change broke my remote vendor systems, and my customers here can't wait two weeks !!
You see, in here, it works a little different from in the Real World.
If something doesn't work as advertised, we really can't expect any payment for it.
This in in stark contrast to how it works at a certain RW company, to whom I have to pay US$350+ every month, despite that dwell is not working, the server crashes, I seldom get any replies to bug reports or help requests, or if I do, it takes 2-3 weeks.
But I guess that's life. (second one that is).

/RR
_____________________

Goodbye and thanks for all the prims.
Moleculor Satyr
Fireflies!
Join date: 5 Jan 2004
Posts: 2,650
11-10-2004 13:20
From: Adam Zaius
I know, this one poses a problem. I'd even settle for having [email]UUID@simXYZ.agni.lindenlab.com[/email] if we could have it pushed into the script automagically via the email event (llGetSimulatorHostname() seems perfect for this?). Although, I agree with you - there shouldnt be any reason why you cannot create a routing table that updates whenever a script with an email() event in it, is loaded in a sim.

-Adam


ONLY AS AN ALTERNATIVE OPTION!

I still would want the "non-push" email too, damnit. The one that works much the same way the one we have now does.

And quite honestly, I'd rather they work on getting XML-RPC implimented, particle system improvments, land-info polling, llCreateNotecard(), and other, more important things than a pushy email system.
_____________________
</sarcasm>
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
11-10-2004 14:53
From: Adam Zaius
I know, this one poses a problem. I'd even settle for having [email]UUID@simXYZ.agni.lindenlab.com[/email] if we could have it pushed into the script automagically via the email event (llGetSimulatorHostname() seems perfect for this?). Although, I agree with you - there shouldnt be any reason why you cannot create a routing table that updates whenever a script with an email() event in it, is loaded in a sim.

-Adam


I'll support that.

The problem with making a push email system is that only a few mail servers work that way (I think FirstClass does this to some extent, but then FirstClass is closed source). The forwarding could be done... NOOOO IT'S such a hack never mind. Just make an object<->object messaging protocal. I don't care what it is, i don't care even if it's XML-RPC. (still hopes for his InstantMessageObject)
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly

Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
Francis Chung
This sentence no verb.
Join date: 22 Sep 2003
Posts: 918
11-10-2004 18:26
From: Adam Zaius
Hrrm, I cant but feel this may not be the best way of doing it, as far as I can see, this will only cause multithreading, but unlike ordinary multithreading, these scripts will have timers.


Just tried this trick - it's not as trivial as I hoped.

If you have multiple scripts calling llGetNextEmail() you have this tendency to receive the email message more than once. :P
_____________________
--
~If you lived here, you would be home by now~
Antagonistic Protagonist
Zeta
Join date: 29 Jun 2003
Posts: 467
11-10-2004 23:22
bleh just read the post. This does suck.

Possible method for multithreading to make it poll every 2 seconds. You'll need 3 scripts to poll for email and one controller.

Assign each polling script a node number as a variable. 0,1,2 etc.

Have the controller "pulse" a linked message every 2 seconds with the current node number, then increment it.

Have the polling scripts respond to the linked message when they hear their node number and then poll for email.


Dont know if this would result in identical messages being retreived though :/ Guess I'll have to try. I use packet sequence numbers at this layer of my network protocol anyway, so it really wouldnt affect me too much as my system already checks for the case of out of order and/or "ghosted" emails but I can see where it has the potental for irritation.

I'll have to agree with everyone else though: Make object to object RPC work. k thx :-)

-AP
Carnildo Greenacre
Flight Engineer
Join date: 15 Nov 2003
Posts: 1,044
11-11-2004 01:39
If you were to get full XML-RPC working, this whole email mess would go away.

That means object->object RPC, object->outside RPC, and outside->object RPC. That also means no delays in the RPC system.
_____________________
perl -le '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++;'
Azelda Garcia
Azelda Garcia
Join date: 3 Nov 2003
Posts: 819
11-11-2004 02:32
> Just tried this trick - it's not as trivial as I hoped.
>
> If you have multiple scripts calling llGetNextEmail() you have this tendency to receive the email message more than once. :P

Well, you basically replace one script that looked like:

MyEmailScript:
CODE

email()
{
}
timer()
{
   llGetNextEmail()
}



with 6:

MyEmailScript:
CODE

email()
{
}


Pollers 1 thru 5:
CODE

timer()
{
   llGetNextEmail();
}


Course you need a little bit of magic in the pollers so that the GetNextEmail is called once a second and not 5 times in the first second and nothing for 5 seconds, but we're all capable of figuring that out. *cough*llGetTimeOfDay() % 5 *cough*.

Azelda
_____________________
Francis Chung
This sentence no verb.
Join date: 22 Sep 2003
Posts: 918
11-11-2004 03:53
From: Azelda Garcia

MyEmailScript:

[snippity snip]

Course you need a little bit of magic in the pollers so that the GetNextEmail is called once a second and not 5 times in the first second and nothing for 5 seconds, but we're all capable of figuring that out. *cough*llGetTimeOfDay() % 5 *cough*.


Oh sweet, nice trick Az :)

Email in<->out with this trick is around 1 second RTT now. *cheers*

*wonders what LL thinks of us doing this*

Oh, and for what it's worth, I've found that the time functions, other than llGetTime() aren't particularly great for sub-second accuracy. I use a link message pulse myself. *shrugs* Shouldn't matter too much in this case, but if you want to poll faster than 1 second...


From: someone

UNIX Fortune: Elapsed Time: 0.997966 seconds
UNIX Fortune: Q: How many IBM CPU's does it take to do a logical right shift? A: 33. 1 to hold the bits and 32 to push the register.
_____________________
--
~If you lived here, you would be home by now~
Azelda Garcia
Azelda Garcia
Join date: 3 Nov 2003
Posts: 819
11-11-2004 04:09
> Oh, and for what it's worth, I've found that the time functions, other than llGetTime() aren't particularly great for sub-second accuracy. I use a link message pulse myself. *shrugs* Shouldn't matter too much in this case, but if you want to poll faster than 1 second...

Well, I have 36 scripts in my object, all communicating with linkmessages. Dont really want to add more linkmessages if I can help it in case I choke the event buffer.

llGetTimeOfDay() works pretty nicely. It gives you sub-second accuracy and doesnt reset at midnight (cf llGetWallclock() which is rounded to nearest second).

> if you want to poll faster than 1 second...

Let's not do that. It might kill the email servers.

Azelda
_____________________
Antagonistic Protagonist
Zeta
Join date: 29 Jun 2003
Posts: 467
11-11-2004 10:26
Definitely a cool trick! I think the link message pulse will work better for me instead of the current time thingy.

I guess if I had 36 scripts in one object communictating, it might be different. However I cant imagine myself crowding that many communicatiing scripts in one one prim. *shrug*

-AP
blaze Spinnaker
1/2 Serious
Join date: 12 Aug 2004
Posts: 5,898
11-11-2004 11:33
Why not just expose the development teams task list to a web page?

This way we can see what you guys are working on for the next dot realease or the next full release..

I assume there is a development team task list..
_____________________
Taken from The last paragraph on pg. 16 of Cory Ondrejka's paper "Changing Realities: User Creation, Communication, and Innovation in Digital Worlds :

"User-created content takes the idea of leveraging player opinions a step further by allowing them to effectively prototype new ideas and features. Developers can then measure which new concepts most improve the products and incorporate them into the game in future patches."
1 2 3