Second Life Wiki - User contributions [en]

LlHTTPRequest

2009-06-25T01:45:37Z

Lex Neva:

{{LSL_Function
|func=llHTTPRequest
|func_id=230
|func_energy=10.0
|func_sleep=0.0
|func_desc=Sends an HTTP request to the specified URL with the body of the request and parameters.
|sort=HTTPRequest
|func_footnote=
|return_type=key
|return_text= that is a handle identifying the HTTP request made.
|p1_type=string|p1_name=url|p1_desc=A valid HTTP/HTTPS URL.
|p2_type=list|p2_name=parameters|p2_desc=configuration parameters, specified as HTTP_* flag-value pairs
[ parameter1, value1, parameter2, value2, . . . parameterN, valueN]
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|constants={{LSL_Constants_HTTP}}
{{LSL_Constants/HTTP_Headers}}
|spec
|caveats=
*If there is a space in '''url''', the [[http_response]] status code will be 499.
*The response body is limited to 2048 bytes; if it is longer it will be truncated.
*Requests are throttled on a per [[object]] basis (not per prim).
**Requests are throttled to a maximum of 25 requests per 20 seconds. This is to support a sustained rate of 1 per second or a burst of up to 25.
***See [http://forums.secondlife.com/showthread.php?t=108960 this thread] and [http://forums.secondlife.com/showthread.php?t=109571 this thread] for more details.
*Cannot be used to load textures or images from the internet, for more information see [[Web Textures]].
*If the accessed site is relying on the LSL script to report L$ transactions, then it '''must''' check the X-SecondLife-Shard header to see if the script is running on the beta grid.
* Some servers will return a 405 error if you send POST to a file that can't accept metadata, such as a text or HTML file. Make sure you use the GET method to ensure success in any environment.
* While the HTTP status code from the server is provided to the script, redirect codes such as 302 will result in the redirect being automatically and transparently followed, with the resulting response being returned.
|examples=<lsl>key http_request_id;

default
{
state_entry()
{
http_request_id = llHTTPRequest("url", [], "");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id == http_request_id)
{
llSetText(body, <0,0,1>, 1);
}
}
}</lsl>

Example PHP test script:
<php><?php header("content-type: text/plain; charset=utf-8"); ?>
Headers received:
<?php

/**
* @author Wouter Hobble
* @copyright 2008
*/

foreach ($_SERVER as $k => $v)
{
if( substr($k, 0, 5) == 'HTTP_')
{
print "\n". $k. "\t". $v;
}
}
?></php>

example wrapper script Both capturing apache headers and global methodes
<php>
<?PHP
// Author Waster Skronski.
// General Public License (GPL).
// Mind that some headers are not included because they're either useless or unreliable.
$USE_APACHE_HEADERS = TRUE; // switch to false if you need cgi methods
if ($USE_APACHE_HEADERS)
{
$headers = apache_request_headers();
$objectgrid = $headers["X-SecondLife-Shard"];
$objectname = $headers["X-SecondLife-Object-Name"];
$objectkey = $headers["X-SecondLife-Object-Key"];
$objectpos = $headers["X-SecondLife-Local-Position"];
$ownerkey = $headers["X-SecondLife-Owner-Key"];
$ownername = $headers["X-SecondLife-Owner-Name"];
$regiondata = $headers["X-SecondLife-Region"];
$regiontmp = explode ("(",$regiondata); // cut cords off
$regionpos = explode (")",$regiontmp[1]); //
$regionname = substr($regiontmp[0],0,-1); // cut last space from simname
} else {
$db = $GLOBALS;
$headers = $db['HTTP_ENV_VARS'];
$objectgrid = $headers["HTTP_X_SECONDLIFE_SHARD"];
$objectname = $headers["HTTP_X_SECONDLIFE_OBJECT_NAME"];
$objectkey = $headers["HTTP_X_SECONDLIFE_OBJECT_KEY"];
$ownerkey = $headers["HTTP_X_SECONDLIFE_OWNER_KEY"];
$objectpos = $headers["HTTP_X_SECONDLIFE_LOCAL_POSITION"];
$ownername = $headers["HTTP_X_SECONDLIFE_OWNER_NAME"];
$regiondata = $headers["HTTP_X_SECONDLIFE_REGION"];
$regiontmp = explode ("(",$regiondata);
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1);
}
?>
</php>

<div style="display:none;"><lsl></lsl></div>
|helpers
|also_header
|also_events={{LSL DefineRow||[[http_response]]}}
|also_functions={{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_articles={{LSL DefineRow||[[Simulator IP Addresses]]}}
|also_footer
|notes=If for some reason while using llHTTPRequest/http_response you are unable to parse a known good RSS feed or some other form of web contents, you will need to work around it outside of SecondLife. This is unlikely to change in the near future since checking the headers requires more overhead at the simulator level.

You may find that some web servers return either a null or a nonsensical result when llHTTPRequest is used, even though the same URL in a PC web browser returns the expected result. This may be due to the fact that the llHTTPRequest User Agent string is not recognised by some web servers as it does not contain "Mozilla", which would identify it as a web browser instead of, for example, a Shoutcast or an RSS client. A workaround is to append " HTTP/1.0\nUser-Agent: LSL Script (Mozilla Compatible)\n\n" or similar to the URL string, which will kludge the HTTP request to look like it originates from a web browser.

CGI environments may place the headers into variables by capitalizing the entire name, replacing dashes with underscores, and prefixing the name with "HTTP_", e.g. "HTTP_X_SECONDLIFE_OBJECT_NAME". PHP $_SERVER variables do this as well.

Apache can include the headers in its logs, using the CustomLog and LogFormat directives. See [http://httpd.apache.org/docs/2.0/mod/mod_log_config.html#formats the docs] for details on the syntax.

|mode
|deprecated
|permission
|cat1=HTTP
|cat2=XML-RPC
|cat3=Communications
|cat4=HTTP/Client
}}

LlHTTPRequest

2009-06-25T01:44:01Z

Lex Neva: add note about HTTP redirects

{{LSL_Function
|func=llHTTPRequest
|func_id=230
|func_energy=10.0
|func_sleep=0.0
|func_desc=Sends an HTTP request to the specified URL with the body of the request and parameters.
|sort=HTTPRequest
|func_footnote=
|return_type=key
|return_text= that is a handle identifying the HTTP request made.
|p1_type=string|p1_name=url|p1_desc=A valid HTTP/HTTPS URL.
|p2_type=list|p2_name=parameters|p2_desc=configuration parameters, specified as HTTP_* flag-value pairs
[ parameter1, value1, parameter2, value2, . . . parameterN, valueN]
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|constants={{LSL_Constants_HTTP}}
{{LSL_Constants/HTTP_Headers}}
|spec
|caveats=
*If there is a space in '''url''', the [[http_response]] status code will be 499.
*The response body is limited to 2048 bytes; if it is longer it will be truncated.
*Requests are throttled on a per [[object]] basis (not per prim).
**Requests are throttled to a maximum of 25 requests per 20 seconds. This is to support a sustained rate of 1 per second or a burst of up to 25.
***See [http://forums.secondlife.com/showthread.php?t=108960 this thread] and [http://forums.secondlife.com/showthread.php?t=109571 this thread] for more details.
*Cannot be used to load textures or images from the internet, for more information see [[Web Textures]].
*If the accessed site is relying on the LSL script to report L$ transactions, then it '''must''' check the X-SecondLife-Shard header to see if the script is running on the beta grid.
* Some servers will return a 405 error if you send POST to a file that can't accept metadata, such as a text or HTML file. Make sure you use the GET method to ensure success in any environment.
* While the HTTP status code from the server is provided to the script, redirect codes such as 302 will result in the redirect being automatically and transparently followed by SL, with the resulting response being returned.
|examples=<lsl>key http_request_id;

default
{
state_entry()
{
http_request_id = llHTTPRequest("url", [], "");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id == http_request_id)
{
llSetText(body, <0,0,1>, 1);
}
}
}</lsl>

Example PHP test script:
<php><?php header("content-type: text/plain; charset=utf-8"); ?>
Headers received:
<?php

/**
* @author Wouter Hobble
* @copyright 2008
*/

foreach ($_SERVER as $k => $v)
{
if( substr($k, 0, 5) == 'HTTP_')
{
print "\n". $k. "\t". $v;
}
}
?></php>

example wrapper script Both capturing apache headers and global methodes
<php>
<?PHP
// Author Waster Skronski.
// General Public License (GPL).
// Mind that some headers are not included because they're either useless or unreliable.
$USE_APACHE_HEADERS = TRUE; // switch to false if you need cgi methods
if ($USE_APACHE_HEADERS)
{
$headers = apache_request_headers();
$objectgrid = $headers["X-SecondLife-Shard"];
$objectname = $headers["X-SecondLife-Object-Name"];
$objectkey = $headers["X-SecondLife-Object-Key"];
$objectpos = $headers["X-SecondLife-Local-Position"];
$ownerkey = $headers["X-SecondLife-Owner-Key"];
$ownername = $headers["X-SecondLife-Owner-Name"];
$regiondata = $headers["X-SecondLife-Region"];
$regiontmp = explode ("(",$regiondata); // cut cords off
$regionpos = explode (")",$regiontmp[1]); //
$regionname = substr($regiontmp[0],0,-1); // cut last space from simname
} else {
$db = $GLOBALS;
$headers = $db['HTTP_ENV_VARS'];
$objectgrid = $headers["HTTP_X_SECONDLIFE_SHARD"];
$objectname = $headers["HTTP_X_SECONDLIFE_OBJECT_NAME"];
$objectkey = $headers["HTTP_X_SECONDLIFE_OBJECT_KEY"];
$ownerkey = $headers["HTTP_X_SECONDLIFE_OWNER_KEY"];
$objectpos = $headers["HTTP_X_SECONDLIFE_LOCAL_POSITION"];
$ownername = $headers["HTTP_X_SECONDLIFE_OWNER_NAME"];
$regiondata = $headers["HTTP_X_SECONDLIFE_REGION"];
$regiontmp = explode ("(",$regiondata);
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1);
}
?>
</php>

<div style="display:none;"><lsl></lsl></div>
|helpers
|also_header
|also_events={{LSL DefineRow||[[http_response]]}}
|also_functions={{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_articles={{LSL DefineRow||[[Simulator IP Addresses]]}}
|also_footer
|notes=If for some reason while using llHTTPRequest/http_response you are unable to parse a known good RSS feed or some other form of web contents, you will need to work around it outside of SecondLife. This is unlikely to change in the near future since checking the headers requires more overhead at the simulator level.

You may find that some web servers return either a null or a nonsensical result when llHTTPRequest is used, even though the same URL in a PC web browser returns the expected result. This may be due to the fact that the llHTTPRequest User Agent string is not recognised by some web servers as it does not contain "Mozilla", which would identify it as a web browser instead of, for example, a Shoutcast or an RSS client. A workaround is to append " HTTP/1.0\nUser-Agent: LSL Script (Mozilla Compatible)\n\n" or similar to the URL string, which will kludge the HTTP request to look like it originates from a web browser.

CGI environments may place the headers into variables by capitalizing the entire name, replacing dashes with underscores, and prefixing the name with "HTTP_", e.g. "HTTP_X_SECONDLIFE_OBJECT_NAME". PHP $_SERVER variables do this as well.

Apache can include the headers in its logs, using the CustomLog and LogFormat directives. See [http://httpd.apache.org/docs/2.0/mod/mod_log_config.html#formats the docs] for details on the syntax.

|mode
|deprecated
|permission
|cat1=HTTP
|cat2=XML-RPC
|cat3=Communications
|cat4=HTTP/Client
}}

Message Queue Evaluation Notes

2009-04-01T00:39:21Z

Lex Neva: removed unnecessary profanity

= Summary and Overview =

One of the infrastructure tools that we've identified for the future internal architecture of Second Life is messaging. Message queuing systems allow systems that send messages to not have to worry about how they will be delivered, and allow consumers of messages to gather whichever ones interest them, at their own pace.

Ideally we'd have a completely scaleable system that clients could treat as singular black box. It would act as a well-known cluster to which senders or receivers of messages could connect, and be able to communicate asynchronously to or from anywhere else on the grid. Unfortunately it seems as though this dream, like so many others, is unattainable by any currently available software. We investigated around 15 open source systems that were explicitly designed for message queueing and found that none of them achieved this ideal.

Our use cases mostly involve very large numbers of queues; the smallest number we're even considering is double the number of concurrent users. Our largest use case would be of the same order of magnitude as registered users. This means that we have to plan for millions, and probably tens or hundreds of millions, of message queues, since we want whatever system we choose to last us until then. Pretty much all of the message queue systems we investigated are intended to maximize message throughput rather than number of consumers. The clustering that they implement mainly serves as additional horsepower to deliver more message throughput. In particular the clustering we've seen replicates all state to every machine in the cluster, meaning that the cluster cannot add queues beyond the capacity of an individual node. In order to have a solution that scales in terms of number of queues, each node will have to be able to contain a subset of the global state -- it actually seems as though such a message system would want to be coupled with a distributed storage system.

In any case, given that we expect that we'd have to develop our own queue scaling solution that involves partitioning, which may or may not be a task we are interested in taking on, the strongest candidates are
RabbitMQ and Apache QPID. Both are mature products that support AMQP (though they support different versions). Both have strong vendor support, and both have good single-host performance numbers. There is some more investigation to be done -- we'd like to know their true maximum capacity when clustered, to evaluate whether it's worth clustering at all, given that we have to implement partitioning ourselves anyway.

We're unfortunately pretty far from having closed the case on which technology to choose, or even if we can use any of these at all. Investigation will continue!

== Criteria ==

Questions
# Support for consuming messages in our two main languages, Python and C++
# Support for producing them in all of our main languages (or, e.g., an HTTP gateway)
# What's the raw message rate that a single server can handle at different message sizes (e.g. 1 byte, 128 bytes, 1K, 128K)?
# What are the latency figures for these message rates?
# What are the server's clustering characteristics?
#* HA/failover
#* scalability for message quantity
#* scalability for number of clients/queues
# What about cross-colo traffic? Does it do SSL, does it need tunneling, is it designed to deal with interrupted communications?
# How do the health of the protocol standard, the software, and the community look?
# Can we engage people on support and development contracts if necessary?
# Is it possible to set up persistent queues, where undelivered messages will survive server restarts? For some interesting perspectives, see [http://www.rockstarprogrammer.org/post/2008/oct/04/what-matters-asynchronous-job-queue/ "What Matters in an Asynchronous Job Queue"] and [http://groups.google.com/group/beanstalk-talk/browse_thread/thread/e8d1a6ea80f0d57a this discussion on persistence and failure scenarios].

The major use cases that we believe could be implemented with message queues are these:
* IM
* blue box notifications in the viewer
* group notices
* group chat
* group votes
* presence notifications
* anything else that currently is an [http://wiki.secondlife.com/wiki/ImprovedInstantMessage ImprovedInstantMessage]
* friendship
* details of registration such as initial inventory
* requests to regenerate map tiles

Many other uses that we haven't put up there would arise when developing various applications. Note that we '''do not''' intend to expose the message queue system directly to the viewer; we would use it instead for behind-the-scenes implementation of the above use cases. Discussing the protocol by which the viewer sends and receives messages with the server is far outside the scope of this research.

The primary use case that we examined was that of group chat. This is the most obvious use that we'd put message queues to, and it's also one of the only use cases up there that is a current pain point for Residents. Here are some numbers describing group chat, which were captured at 11am one day:

* online residents: ~68,000
* number of group chats: 131953
* number of memberships: 629637
* avg number of groups/resident: 9.3
* average group size: 4.8
* most online members in a group: 785
* stdev group size: 13.1
* group churn/second: 23.2
* membership churn/second: 260
* messages sent/second: 8.6

We want to pick a technology that can at minimum handle 4x these numbers, and ideally could horizontally scale across the most important axes to us: number of group chats, number of memberships, and messages/second.

Group churn represents the number of groups added or removed from the system every second. In an AMQP-based system a "group" would be added when someone binds the first queue to the a key representing the group's id, and the group would be dropped when the last binding to the key is removed. In any routing system of this nature, there will be two data structures that are the inverse of each other: one is queuename->keys table and the other is the keys->queuenames table. Group churn would primarily affect the keys->queuenames table.

Membership churn comes from agents joining and leaving groups, and is indirectly related to group churn. There is vastly more membership churn because each agent is in roughly 9 groups -- one agent logs in for 15 seconds and then logs out, that's 18 points of "churn". In an AMQP-based system this churn would be visible as bindings being added and dropped, which would thus affect the queuename->keys table.

Both types of churn are substantially higher than messaging rate. Even if we successfully implement a feature that will allow residents to opt out of joining group chat on login, I'd guess that we'd see at most a 75% reduction in churn as a result, which would still leave membership churn nearly an order of magnitude larger than messages sent.

The group size metrics are interesting because it implies that most groups are pretty small. The downside is we have roughly 2 unique groups for every concurrent resident, so our group system has to scale along that axis very well.

Overall, these numbers are a real whack upside the head because they reveal that for our particular use case, we worry far more about number of queues, and ability to handle high churn, than we do about message delivery rate. Most of the benchmarks regarding the software we evaluated optimize for message rate rather than churn or quantity of queues.

Note that [http://gojko.net/2009/03/16/qcon-london-2009-upgrading-twitter-without-service-disruptions/ Twitter has a similar set of requirements] (complete with startlingly low message rate), though they don't have such tight latency requirements as we do.

= Scaling =

Given that we haven't found any system that provides seamless scaling along the axis of queues, we have come up with some designs for how the system could be partitioned. Any partition scheme is a bit of a downer because then the clients have to know about the partitioning.

The best way to partition is probably to partition on routing key. When a client wants to receive messages for a routing key, or when a sender wants to send to a routing key, the first thing it does is ask a redirector which slice to talk to. The system would look like:

[[Image:Message_queue_partition_unclustered.png]]

This system has the property that each client will be talking to as many slices as routing keys of interest (proportional, anyhow). This may be acceptable for an application where there's only a finite number of routing keys that any particular client may be interested in (such as group chat, where there's an upper limit on the number of groups a resident may be in).

We could cut down on the sheer quantity of connections by using clustering to reduce the number of slices. The messaging technologies we looked at support clustering in a way that would allow us to create clusters of 2-3 nodes that have roughly 1.5-2 times the quantity of queues as a single node. This would be a more complex system than not using clustering at all, but it would reduce the number of slices, and thus connections, by a factor of 1.5-2, which may be important.

[[Image:Message_queue_partition_clustered.png]]

The clustered partition scheme isn't fundamentally different than the unclustered partition scheme, it's just a constant-factor optimization. However, if the cluster added high-availability properties (such as being able to continue running even when one node fails), then it would be worth it.

= Currently Available Software =

== AMQ Protocol ==

AMQP is a developing standard that is aimed pretty squarely at our use cases: high-performance, flexible, message routing and delivery. The standard is being iterated upon and is not finalized yet. This is a risk factor because it's a moving target and all current editions are mutually incompatible -- the 0-10 edition is nontrivially different from 0-8, and I've read some rumors that the next edition removes or changes some of the core concepts in a dramatic way.

We believe that AMQP is the appropriate standard for our use cases; therefore we investigated the AMQP servers much more heavily. Here's [http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ a decent example] of how to apply AMQP to a particular use case (with emphasis on Rabbit).

* [https://launchpad.net/txamqp Twisted AMQP], a 0-8 and 0-9 Twisted Python client
* [http://hopper.squarespace.com/blog/2008/6/21/build-your-own-amqp-client.html Build your Own AMQP Client]

=== RabbitMQ ===
[http://www.rabbitmq.com/ Rabbit Home]

RabbitMQ is already installed in our image and is currently being deployed by the data warehousing team (Ivan in particular) to handle syslog message delivery.

# Support for consuming messages in our two main languages, Python and C++?
#* python only, apparently!
# Support for producing them in all of our main languages (or e.g. an HTTP gateway)
#* Yes, they have HTTP and Stomp gateways.
# What's the raw message rate that a single server can handle at different message sizes (e.g. 1 byte, 128 bytes, 1K, 128K)?
#* Not investigated because widespread reports indicate that this number is very high; this will not be a bottleneck.
# What are the latency figures for these message rates?
#* Latency is in tens of microseconds.
# What are the server's clustering characteristics?
#* HA/failover
#** Weak. If clustered, the cluster behaves poorly when nodes go away, until their data is restored; see [http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-February/003338.html]. The developers suggested setting up two queues on two hosts and doing client-side duplicate removal, but this seems like we'd be doing work that the message queue system should be doing for us.
#* scalability for message quantity
#** Untested but theoretically clustering improves this.
#* scalability for number of clients/queues
#** Not supported. Currently a single Rabbit node will support up to 250,000 queues before consuming all available memory. If clustered with a second host, the second host will have 800 MB of its memory consumed as well even though it's not doing any work. This is because all hosts in a cluster contain a complete copy of the routing tables. The data structures required for queues themselves are stored on the first host, and consume the other 1200 MB available. This implies that if queues were evenly added to both hosts, we could probably get up to around 400,000 queues total. We'd like to test that hypothesis.
# What about cross-colo traffic?
#* Not if hosts in a cluster are cross-colo from each other. There's [http://hopper.squarespace.com/blog/2008/6/22/introducing-shovel-an-amqp-relay.html a plugin called shovel] that is explicitly designed for cross-colo situations, though. However, if clustering doesn't support the number of queues we want, there's little reason to worry about clusters that span colos. The wire protocol is believed to be robust against flaky connections; it's hard to test that though.
# Does it do SSL, does it need tunneling, is it designed to deal with interrupted communications?
#* [http://www.rabbitmq.com/api-guide.html#ssl Supports SSL], however this appears to be both outside of the spec and a bit of a hack. AMQP as a whole doesn't yet have an ssl story, so we'd have to go outside the spec to achieve security.
# How do the health of the protocol standard, the software, and the community look?
#* Strong. Rabbit in particular has a relatively strong community -- ~500 messages per month on mailing list and key developers respond frequently.
# Can we engage people on support and development contracts if necessary?
#* Yes, we already have contacts with them and have already gotten enhancements.
# Is it possible to set up persistent queues, where undelivered messages will survive server restarts?
#* Yes. These are not replicated.

Notes:
* ~5000 lines of code (i.e. not many places to hide bugs)
* Queues can fill up available memory if clients can't consume non-immediate messages quickly enough (immediate messages get discarded if a client can't consume them).
* [http://forum.trapexit.org/mailinglists/viewtopic.php?p=42890&sid=cb78a92ab50adefbf60e3770c0ba7e9b RabbitMQ Performance Testing and Troubles]
* Even in clustered configuration, queues only reside on a single machine.
* [http://hopper.squarespace.com/ Blog oriented towards Rabbit]
* http://everburning.com/news/tag/amqp/ Ruby-oriented but examples are pretty clear
* http://www.somic.org/d/samovskiy-amqp-rabbitmq-cohesiveft.pdf
* http://somic.org/2008/11/11/using-rabbitmq-beyond-queueing/
* http://www.lshift.net/blog/category/lshift-sw/rabbitmq/
* In our tests, if you create a bunch of auto-delete queues (~100), the rabbit server becomes unresponsive for 2 minutes after you remove the clients (presumably because the server starts deleting the queues when you remove the clients). We generally have to restart the server. This may be problematic in production; we should generate a test case that repros this.
* py-amqplib requires Python >2.4
* Collected data: http://spreadsheets.google.com/a/lindenlab.com/ccc?key=p0_PzEgG1YZeKbg_y4n1nFg
* Restarting individual hosts in a cluster is seamless -- it totally comes back together without any extra work, yay.
* Rabbit (and mnesia) is very sensitive to DHCP/DNS failures. We had a DHCP failure on our host, and it corrupted everything, leading to rogue beam processes and messed up mnesia files. Had to nuke everything.
* HA by creating multiple queues on multiple hosts: http://www.nabble.com/Re:-Q-replication-anxiety-p21953124.html
* Discussing huge numbers of queues: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-February/003431.html
* Discussion about what happens when one node in a cluster goes away, and how it's less than ideal: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-February/003338.html

=== Apache QPID/Red Hat MRG ===
http://cwiki.apache.org/confluence/display/qpid/Index
http://www.redhat.com/mrg/

QPID is sort of a compilation project from Apache. They have a pile of clients, and two brokers that each support different versions of the AMQP standard. The C++ broker appears to be where the good stuff is at. Installing it was not difficult -- it only required a few additional Boost libraries to be installed.

# Support for consuming messages in our two main languages, Python and C++
#* Yes, comes bundled with clients in both.
# Support for producing them in all of our main languages (or e.g. an HTTP gateway)
#* No, only python and C++.
# What's the raw message rate that a single server can handle at different message sizes (e.g. 1 byte, 128 bytes, 1K, 128K)?
#* Untested; again, not likely to be a bottleneck.
# What are the latency figures for these message rates?
#* Untested, it comes with a perftest tool that we should run.
# What are the server's clustering characteristics?
#* HA/failover
#** [http://cwiki.apache.org/confluence/display/qpid/queue+state+replication Queue Replication] could be used in conjunction with [http://qpid.apache.org/connection-url-format.html client failover] to implement HA queues. Untested.
#* scalability for message quantity
#** Unknown.
#* scalability for number of clients/queues
#** The C++ broker tops out at around 500,000 queues per host. We haven't yet determined whether this number can be increased by [http://cwiki.apache.org/confluence/display/qpid/Using+Broker+Federation clustering/federation].
# What about cross-colo traffic? Does it do SSL, does it need tunneling, is it designed to deal with interrupted communications?
#* Same as rabbit; these questions are properties of AMQP.
# How do the health of the protocol standard, the software, and the community look?
#* Relatively small community, though active. 721 messages to qpid-dev list in December 2008, though 90% seem to be JIRA spam; only 71 to qpid-users.
# Can we engage people on support and development contracts if necessary?
#* Red Hat supports a version called MRG -- unknown whether we could get them to help us use it on Debian. ;-)
# Is it possible to set up persistent queues, where undelivered messages will survive server restarts?
#* Yes.

Notes:
* MRG is based on QPID, per [http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.0/html/Messaging_Installation_Guide/sect-Messaging_Installation_Guide-Installing_RHM-Installing_RHM_on_RHEL5.html this page].
* Client libs: C++, Java, Ruby, Python, C#. Only the C++ client appears to have any documentation.
* http://cwiki.apache.org/confluence/display/qpid/Documentation <-- this link was surprisingly hard to find
* Python client is annoying to use. Before even getting started you have to set an environment variable pointing at the spec (<code>export AMQP_SPEC=/tmp/qpid/qpid-M4/specs/amqp.0-10.xml</code>) and modify the spec file itself to point at the DTD because relative paths don't work for some reason. The code is written poorly; no comments, run-on functions, uses long-deprecated things like raise "string" everywhere. Also, it's slow as hell starting up and at runtime. Finding another 0-10 compatible python client would be important.

=== OpenAMQ ===
http://www.openamq.org/
{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| This product has been eliminated from the race
|}

* http://www.openamq.org/doc:user-3-advanced
* Supports HA via primary/secondary failover, EXCEPT "What we do not attempt to do includes: ... The handling of persistent messages or transactions in any way.....Replication of exchanges, queues, bindings, or messages between servers. All server-side state much be recreated by applications when they fail over."
* HA support is mutually exclusive from federation support.
* Supports federation; we'd want to use the "locator" federation type.
* Seems immature; few docs, not a strong community -- however, it's actually pretty old.
* Implements a subset of AMQP 0.9
* http://amqp.wdfiles.com/local--files/deleted:library:cluster/clustering.pdf
* Java centric, no bindings for other languages we love to use.

== XMPP ==

=== ejabberd ===
http://www.ejabberd.im/
{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| This product has NOT been eliminated, but we did not evaluate it for want of time.
|}

Clients: http://www.jabber.org/web/Clients

* Widely deployed and super-popular.
* XMPP seems to not be the best fit for generic applications -- it seems that it only solves the group-chat and person-to-person IM cases.

==== AMP Extension ====
http://xmpp.org/extensions/xep-0079.html
Message queue extension, available for ejabberd via [https://support.process-one.net/browse/EJAB-449 this patch].

This extension adds:
* Reliable data transport -- the sender requires notification (positive and/or negative) of message delivery.
* Time-sensitive messages -- the message is valid only until a certain date and time.
* Transient messages -- the message should not be stored offline for later delivery.

The AMP extension is immature and has no client support -- we'd be going it ourselves if we wanted to use that. We might decide that we don't need the AMP extension's semantics.

==== PubSub Extension ====

http://www.ejabberd.im/mod_pubsub-usage

http://ppolv.wordpress.com/2007/11/28/managing-a-jabber-pubsub-service/

Doesn't seem to be client support for this, but it's probably better than AMP extension client support and I haven't looked especially hard yet.

== Stomp ==
Products that support primarily the Stomp protocol.

http://stomp.codehaus.org/Protocol

Stomp is a message passing scheme that is tremendously simple. It kinda looks like HTTP, but it's actually even simpler. The simplicity is both a strength and a weakness.
* Human-readable
* Requires null-termination of message bodies; the spec implies that it's OK to include nulls in the message body if a content-length header is included, but if the header is not supplied nulls are not acceptable. [http://cometdaily.com/2008/10/08/scalable-real-time-web-architecture-part-1-stomp-comet-and-message-queues/ This article] and subsequent discussion is interesting.
* Underspecified header syntax means implementations might differ w.r.t. all-dashes, spaces between : and header body, capitalization, etc.

There are stomp clients written in nearly every language; since the protocol is so simple it seems as if people write new clients whenever they encounter even the slightest problem with someone else's client.
* stomp.py -- nicely written, but seems to be just barely maintained by a guy who doesn't really use it any more. Its error reporting sucks (prints java exceptions to stdout, doesn't give any feedback to python program). But it works!

=== ActiveMQ ===
http://activemq.apache.org/

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race
|}

Related Jira : <jira>DEV-19958</jira>

* HA via master/slave failover built-in: http://activemq.apache.org/masterslave.html It's not great, but it's better than "you lost all your shit!"
* Does not support AMQP (how did we miss this earlier?)
* Clustering built-in with autodiscovery. It's very nice to start up activemq on two machines and see them find each other automagically.
* Broker fails after opening 700 queues on a node due to too many open files -- apparently it has a tempfile for each queue, and an open file for each JAR (of which there are 124!), and 60 miscellaneous filehandles. The number of open files does not decrease when the client quits. Some googling implies that there are numerous bugs in ActiveMQ relating to leaked filehandles.
* Even if you cluster two nodes together, each created subscription opens a new filehandle on both nodes in the cluster! This means that the total number of queues creatable in a clustered system is very small.

=== Sprinkle ===

http://www.thuswise.org/sprinkle/index.html

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race
|}

* Consumes 100% of CPU when idle.
* Requires an external process to create a new directory for each queue -- no way to create queues by talking to the server (unless you hook up a demon listening to a special meta-queue for messages to create new queues...an approach that is appealing in its purity, but...no)

== JMS ==

JMS is a Java API for asynchronous messaging. In a charming bit of java-centrism it specifies the API that a java program sees, but not a wire protocol or anything like that; I can only assume that each client is intended to develop its own custom wire protocol for talking to the broker, but there isn't much information about this out there. Some of the clients that support Stomp or AMQP also support some subset of JMS, and presumably the JMS API simply uses Stomp or AMQP as the wire protocol. The development of the wire protocols have been influenced somewhat by the needs of JMS.

=== OpenMQ ===

https://mq.dev.java.net/about.html

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race
|}

* Very java-specific.
* This is the free version of [http://www.sun.com/software/products/message_queue/index.xml Java System Message Queue]
* JMS only.

== Other ==
Products that have their own protocol. These are generally less interesting to us because they are already at a disadvantage relative to implementations of a particular protocol in terms of community size, possibility of paid support, and being able to replace them with a different implementation if the need arises. However, we still take these into consideration in the hopes of finding a diamond in the rough.

=== Gearman ===

http://www.danga.com/gearman/

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race
|}

* "Gearman is a system to farm out work to other machines, dispatching function calls to machines that are better suited to do work, to do work in parallel, to load balance lots of function calls, or to call functions between languages."
* Not really what we're looking for.

=== Amazon SQS ===
http://aws.amazon.com/sqs/

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race
|}

* [http://notes.variogr.am/post/67710296/replacing-amazon-sqs-with-something-faster-and-cheaper Performance 40x slower than rabbitmq]
* External hosting raises troubling questions about security/privacy, and the ability of our operations team to handle failure cases (i.e. if SQS goes down we are SOL unless we separately maintain our own compatible farm of servers, in which case we gain little in operational savings)
* External hosting adds non-negligible latency

=== beanstalkd ===
http://xph.us/software/beanstalkd/

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| This product has been eliminated from the race.
|}

* Client libs in Python (2.5), PHP, Perl, but not C++.
* No persistent queues, but one of the touted features is preservation of queue state between server restarts/crashes.
* Here's the protocol doc: http://github.com/kr/beanstalkd/tree/v1.1/doc/protocol.txt?raw=true
* Immature
* Works only with Python-2.6, which is two versions above the installed version on etch.

=== Peafowl ===
http://code.google.com/p/peafowl/
(A light weight server for reliable distributed message passing.)

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| This product has been eliminated prima facie from the race.
|}

* Uses memcache protocol, which is not a message queueing protocol. The argument that we should be using a message queueing protocol rather than a key-value protocol is convincing to us. The impedance mismatch between what the memcache protocol is trying to do and what we want out of a message queue system is quite large and it seems our effort is better spent trying to find something that is designed for the purpose.

=== Starling ===
http://rubyforge.org/projects/starling/

Persistent Message Queue, in Ruby though

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| This product has been eliminated prima facie from the race.
|}

=== SMTP ===

http://www.ietf.org/rfc/rfc2821.txt

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"| Ha ha we're just kidding.
|}

* Very mature protocol
* Many vendors
* Huge community
* Persistent queues only - no support for transient queues
* No built-in CreateQueue/DeleteQueue operations
* No support for transactional messages
* Many failure modes will result in multiple delivery of messages

=== Zero MQ ===

http://www.zeromq.org/

{| class="messagebox standard-talk" style="border: 1px solid #DD8888;"
|-
|align="center"|[[Image:Exclamation.png|Eliminated]]
|align="left" width="100%"|This product has been eliminated from the race. Read "NOTE"
|}

* From above page: ØMQ is already very fast. We're getting 13.4 microseconds end-to-end latencies and up to 4,100,000 messages a second today.
* Papers on Tests - http://www.zeromq.org/area:results
* Not based on [http://amqp.org AMQP] and has an AMQP plugin.
* Chat example: http://www.zeromq.org/code:examples-chat
* Python module's API is currently much simpler when compared to original C++ API. The difference is that Python module doesn't allow for full control of ØMQ threading as C++ does. Instead, the Python module extension creates single I/O thread that can be accessed from a single application thread. This doesn't allow for seamless scaling on multicore boxes. However, it is our intent to expose full ØMQ API via Python in the future.
* NOTE: It looks like the python 0mq extension is broken. The sending and receiving functions work only when they are performed within the same Python process (probably has something to do with the above note about the module API in Python)
* UPDATE to NOTE: Python extension works as advertised using the trunk version. Using this, it was possible to generate 100000 queues, for 4 'clients', and the zmq_server did not bog down the CPU (in fact it hovered around 2%)
* Java wrapper does not work as it fails at <code>System.loadLibrary()</code>

= Reading/Related Links =

* [http://jeremy.zawodny.com/blog/archives/010511.html Open Source Queueing and Messaging Systems?]
* [http://www.cse.ohio-state.edu/~narravul/papers/subramoni_whpcf08.pdf MQP Benchmarking]
* [http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-June/001290.html AMQP vs XMPP/RabbitMQ vs ejabberd]

Bug triage/2008-08-25

2008-09-05T02:55:55Z

Lex Neva:

Talk:Limits

2008-07-05T17:31:19Z

Lex Neva: New page: This page says that the number of people in an estate ban list is limited to 500. As far as I know, it's been 300 for a year or so. Did this change recently, maybe in the RC client? ~~~~

This page says that the number of people in an estate ban list is limited to 500. As far as I know, it's been 300 for a year or so. Did this change recently, maybe in the RC client? [[User:Lex Neva|Lex Neva]] 10:31, 5 July 2008 (PDT)

LlMessageLinked

2008-05-15T18:23:51Z

Lex Neva:

{{LSL Function/link}}{{LSL_Function
|func_id=164|func_sleep=0.0|func_energy=10.0
|func=llMessageLinked|sort=MessageLinked
|p1_type=integer|p1_name=linknum|p1_desc=Link number or a LINK_* flag.
|p2_type=integer|p2_name=num|p2_desc=Value of the second parameter of the resulting link_message event.
|p3_type=string|p3_name=str|p3_desc=Value of the third parameter of the resulting link_message event.
|p4_type=key|p4_name=id|p4_desc=Value of the forth parameter of the resulting link_message event.
|func_desc=Triggers a [[link_message]] event with the parameters '''num''', '''str''', and '''id''' in all scripts in the prim(s) described by '''linknum'''. The purpose of this function is to provide same object prim to prim communication.
|func_footer=You can use '''id''' as a second string field (in LSL the [[key]] type is implemented as a [[string]] with just custom operators). Typecasting between string and key types has no effect on the data contained. The sizes of '''str''' and '''id''' are only limited by available script memory.
|constants
|func_footnote
|return_text
|spec
|caveats=*A script can hear its own linked messages if '''linknum''' would target the prim it is in (for example, LINK_SET). This creates the possibility of an infinite loop (a bad thing); be very careful about how messages are handled and passed along.
* Messages sent via llMessageLinked to a script that is [[llSleep|sleeping]], [[LSL Delay|delayed]], or [[lag|lagged]], are queued until the end of the delay. The event queue can hold 64 events.
** If an event is received and the queue is full the event is silently dropped.
** It is possible to generate a script VM lag spike if the message is received by many scripts. This typically occurs when using LINK_SET, LINK_ALL_OTHERS, & LINK_ALL_CHILDREN as '''link_num'''. Script execution can slow or halts. If multiple messages are sent one after another, the lag can cause the event queue to fill.
** Avoid sending link_messages to large numbers of scripts simultaneously.
** Avoid sending link_messages to a target faster then they can be handled.
* When a script [[state]] change, all pending events are deleted, including queued link_messages.
* If '''link_num''' is an invalid link number then the function silently fails.
|examples=<lsl>default{ // assumptions // object name: LSLWiki // script name: _lslwiki
state_entry() {
llMessageLinked(LINK_THIS, 0, llGetScriptName(), "");
}

link_message(integer sender_num, integer num, string msg, key id) {
llOwnerSay(msg);
// the owner of object LSLWiki will hear
// LSLWiki:_lslwiki
}
}</lsl>
|helpers=<lsl>default
{ // Quick and dirty debugging link_messages
link_message(integer sender_num, integer num, string msg, key id) {
llSay(DEBUG_CHANNEL, llList2CSV([sender_num, num, msg, id]));
}
}</lsl>
<lsl>// This is just an example script, you shouldn't handle link message within single script this way.

default{ // To propagate an unlimted number of arguments of any type.
// Presumed, the separator string isn't used in any source string!
state_entry() {
list my_list = [1, 2.0, "a string", <1, 2, 3>, <1, 2, 3, 4>, llGetOwner()];
string list_parameter = llDumpList2String(my_list, "|"); // Typecast list to a string
llMessageLinked(LINK_THIS, 0, list_parameter, "")
}

link_message(integer sender_num, integer num, string list_argument, key id) {
list re_list = llParseString2List(list_argument, ["|"], []); // Typecast string back to a list
}
}</lsl>
|also_header
|also_events={{LSL DefineRow||[[link_message]]|}}
|also_functions
|also_articles
|also_footer
|notes=*Using llMessageLinked in a single prim object allows developers to mitigate some LSL limits by breaking up functionality between cooperating scripts and synchronizing actions. When you do this, be extremely careful not to create infinite loops as mentioned above.
*Some users have noted occasional failures of linked messages when sending a message to a large number of receiving scripts in different prims using LINK_SET, LINK_ALL_OTHERS, & LINK_ALL_CHILDREN (ie. not all prims receive the message). If you encounter this problem, a workaround is to place all child prim scripts in a single prim, using targeted functions like llSetLinkPrimitiveParams to modify the prim in which the script previously resided, and use a single link message to address them. -- [[User:Void Singer|Void Singer]]
|cat1=Communications
|cat2=Link
|cat3=Link Message
|cat4
}}

LlTargetOmega

2008-03-29T17:35:29Z

Lex Neva:

{{LSL Function
|func_id=133
|func_sleep=0.0
|func_energy=10.0
|func=llTargetOmega
|p1_type=vector|p1_name=axis|p1_desc=arbitrary axis to rotate the object around
|p2_type=float|p2_name=spinrate|p2_desc=rate of rotation in radians per second
|p3_type=float|p3_name=gain|p3_desc=also modulates the final spinrate and disables the rotation behavior if zero
|func_footnote
|func_desc=Rotates the object around '''axis''' at '''spinrate''' * [[llVecMag]]('''axis''') in radians per second with strength '''gain'''.
|examples=<lsl>//rotates the x axis once per second,
// rotates the y axis 3 times per second,
// rotates the z axis once every two seconds.
// combined the rate is about 3.20156 revolutions per second

llTargetOmega(<1.0,3.0,0.5>,TWO_PI,1.0);</lsl>
|spec=
===Physics===
*If the object is not physical then the effect is entirely client side.
*If the object is physical then the physical representation is updated regularly.
===Link Sets===
*If the script is attached to the root prim, the entire object rotates around the [[Viewer coordinate frames#Region|region]] '''axis'''
**If the object is attached then it rotates around the attachment '''axis'''
*If the script is attached to a child prim, the prim rotates around the [[Viewer coordinate frames#Local|local]] '''axis'''
**A Child prim can rotate around its own '''axis''' while the entire object rotates around another '''axis'''.
|caveats=*If the object is not physical then the rotation is only a client side effect and it will collide as non-moving geometry.
|constants
|helpers
|also_functions
|also_tests
|also_events
|also_articles
|also_tests={{LSL DefineRow||[[llTargetOmega test]]|}}
|notes=* Use [[llVecNorm]] on '''axis''' so that '''spinrate''' actually represents the rate of rotation.
* Set the gain to zero to disable and remove the rotation behavior, eg llTargetOmega(ZERO_VECTOR, 0, 0);
** A spinrate of 0 with a nonzero gain causes the object to try to stop all spin, rather than simply clearing a previous llTargetOmega() call.
|cat1=Physics
|cat2=Effects
|cat3=Rotation
|cat4
}}

Bug triage/2008-02-25

2008-02-25T19:33:38Z

Lex Neva: /* Misc Pool */

{{Bug triage}}

Next meeting: 2008-02-25 at 12 PM SLT at {{SLurl|region=Hippotropolis|x=241|y=27|z=23|title=Hippotropolis Meeting area}}. See [[Bug triage]] for details.

== Fast Track Import ==

(Move bugs here that have solid repros, or valid patches that you have reviewed)

== Hot by Vote ==

[http://www.sljirastats.com/jira_search.php?search=33&output=wiki High Voted Bugs]

* {{jira|MISC-305}} - Votes: 11 - Parcel Traffic Counts Failing To Update - {{User|Sal Salubrius}}
* {{jira|VWR-2394}} - Votes: 12 - SLRR Trains Keep Disappearing - {{User|Haravikk Mistral}}
* {{jira|VWR-2123}} - Votes: 12 - Parcel name shown in menu bar does not match actual parcel information - {{User|Neo Rebus}}
* {{jira|WEB-493}} - Votes: 17 - Novice users can create issues on JIRA - {{User|Avil Creeggan}}
* {{jira|SVC-1648}} - Votes: 24 - Push applied to avatar by another avatar's scripted attachment does nothing in Havok 4 - {{User|RobbyRacoon Olmstead}}
* {{jira|SVC-255}} - Votes: 14 - Solid, invisible ghost prims - {{User|WarKirby Magojiro}}
* {{jira|VWR-4727}} - Votes: 11 - 1.19.0 ( 79185 ) intermittent short freezes in client every few seconds - {{User|Dizzy Banjo}}

== Patches ==
[http://www.sljirastats.com/jira_search.php?search=34&output=wiki Patches]

* {{jira|VWR-4506}} - Votes: 0 - Implement a unix make install target - {{User|Michelle2 Zenovka}}
* {{jira|VWR-4022}} - Votes: 0 - Improve image upload robustness - {{User|Haravikk Mistral}}
* {{jira|VWR-4480}} - Votes: 1 - Keyboard shortcut for Joystick Flycam - pretty please? - {{User|Domchi Underwood}}

== Misc Pool ==
[http://www.sljirastats.com/jira_search.php?search=35&output=wiki Misc Pool]
* {{jira|VWR-4790}} - Votes: 0 - TP freezes Viewer must Log out and relog Avatar freezes inworld on Relog forcing second Relog - {{User|sweet valentine}}
* {{jira|VWR-4509}} - Votes: 0 - ""Failed to find body part named ... in database."" - {{User|szia shilova}}
* {{jira|MISC-922}} - Votes: 0 - Losing friends intermittantly of my list - {{User|Meaghan Winthorpe}}
* {{jira|SVC-1341}} - Votes: 0 - Mono beta: Large empty loops cause sim to stall. - {{User|davie zinner}}
* {{jira|VWR-4893}} - Votes: 3 - Latest windlight release causes crashing with NVidia GeForce Go 6400 graphics card even on basic settings. - {{User|Fledhyris Proudhon}}
* {{jira|VWR-2606}} - Votes: 0 - Appearance mode produces all black avatar texture and messed up preview windows - {{User|Seifert Surface}}
* {{jira|WEB-330}} - Votes: 0 - Second Life FAQ: ""Is Second Life an MMORPG"" has incorrect response. - {{User|SignpostMarv Martin}}
* {{jira|VWR-5019}} - Votes: 0 - Programme crashes whenever I am trying to edit my avatar's appearance - {{User|Caribkat Jaxxon}}
* {{jira|VWR-4989}} - Votes: 1 - See only blue screen - {{User|annika7 dagger}}
* {{jira|VWR-4515}} - Votes: 0 - Friends dissappaer from list - no, the other one has NOT deleted me - {{User|Rita Munro}}
* {{jira|VWR-4514}} - Votes: 0 - money request was stale...or, when buying a FREE item: [13:07] Buy object failed because you don't have enough L$. !?!? - {{User|luna fratica}}
* {{jira|SVC-1237}} - Votes: 0 - WHen I log in, I get to the screen asking me to select my Avatar's gender, and then the system freezes, and becomes non-responsive if I click again, ever.... - {{User|Caribkat Jaxxon}}
* {{jira|VWR-4980}} - Votes: 0 - When zooming or panning or even just moving in a confined space, SL windlight viewer loses all graphics. Only the frame remains - {{User|Angel Sunset}}
* {{jira|SVC-721}} - Votes: 1 - Havok4 Collision Solver occasionally tosses an avatar when crossing a border over prim - {{User|Teravus Ousley}}
* {{jira|SVC-682}} - Votes: 4 - Objects can enter into No-Object-Entry area. - {{User|Nock Forager}}
* {{jira|VWR-4516}} - Votes: 0 - Atmospheric shaders go fully white/black from some angles at certain times - {{User|Haravikk Mistral}}
* {{jira|VWR-4107}} - Votes: 0 - Change the ""background"" color for textures to transparent - {{User|Domchi Underwood}}
* {{jira|SVC-1467}} - Votes: 8 - PERMISSION_TAKE_CONTROLS doesnt act as designed for scripts in child prims - {{User|Jason Swain}}
* {{jira|VWR-4914}} - Votes: 0 - Starting 2rd viewer in RC2 or Windlight causes one of the viewers to crash. - {{User|Alyx Jonson}}
* {{jira|VWR-4500}} - Votes: 3 - You should be automatically landed when entering a ""No Fly"" area - {{User|Mircea Lobo}}
* {{jira|VWR-4201}} - Votes: 3 - Grabbing prim with llDetectedGrab(), and dragging to the left, rotates camera left. - {{User|Sam Stork}}
* {{jira|SVC-1570}} - Votes: 0 - Camera position shifts in and out for no reason in Havoc 4 beta region - {{User|traverse janus}}
* {{jira|SVC-1569}} - Votes: 0 - Whale Product by STARAX no longer working in Havok4 - {{User|chilly charlton}}
* {{jira|SVC-1144}} - Votes: 2 - replies to offline emails can't contain unicode - {{User|Lex Neva}}
* {{jira|VWR-2624}} - Votes: 0 - <select> boxes in web profile sometimes misbehave - {{User|Lex Neva}}
* {{jira|VWR-815}} - Votes: 3 - cannot change material on link sets - {{User|Lex Neva}}
* {{jira|SVC-578}} - Votes: 6 - "save object back to object contents" no longer works - {{User|Lex Neva}}

== Pre-meeting activity ==

Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.

=== Imported ===

=== Resolved ===
* {{jira|VWR-4778}} - Votes: 0 - Items I have created with onward modify/copy perms become non mod if they contain an animation that is no mod. - {{User|ActingIll Igaly}}
:Can't reproduce - Gigs
* {{jira|VWR-4987}} - Votes: 0 - Contradictory script reports - {{User|eren padar}}
:I'm going to work with the sim owner here, deferred from triage for now.
== Transcript ==
Transcript is/will be at [[{{PAGENAME}}/Transcript]]

== Creating An Agenda ==
{{Bug List Instructions}}

LlGetOwner

2008-02-24T18:16:41Z

Lex Neva:

{{LSL_Function
|func_id=117|func_sleep=0.0|func_energy=10.0
|func=llGetOwner|sort=GetOwner
|return_type=key
|func_footnote
|func_desc
|return_text=that is the current owner of the script.
|spec
|caveats=*When the owner of an object changes, code that depends on this function's return value will not automatically update for the new owner or be automatically re-evaluated.
**This requires the reregistration of [[llListen|listens]] and [[llRequestPermissions|requesting of permissions]] from the new owner as needed.
***This is not limited to listens and permissions but anything that caches the return value, it is up to the programmer to work around this limitation.
**Detection of owner change can be achieved with the [[changed]] event in conjunction with the [[CHANGED_OWNER]] flag (see the first example) or by storing the old value and periodically (e.g. in [[on_rez]]) checking if it has changed. Both techniques are valid though the latter will not detect the sale of the object if it is sold with "sell original" in-world and not picked up.
|constants
|examples=<lsl>default
{
state_entry()
{
llInstantMessage(llGetOwner(), "Only you can hear me. Isn't that eerie.");
}

changed(integer change)
{
if (change & CHANGED_OWNER)
llResetScript();
}
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetCreator]]|}}
{{LSL DefineRow||[[llGetOwnerKey]]|}}
{{LSL DefineRow||[[llDetectedOwner]]|}}
|also_tests
|also_events
|also_articles
|notes
|cat1=Owner
|cat2=Object
|cat3=Key
|cat4
}}

LlGetOwner

2008-02-24T04:31:27Z

Lex Neva: removed incorrect information

{{LSL_Function
|func_id=117|func_sleep=0.0|func_energy=10.0
|func=llGetOwner|sort=GetOwner
|return_type=key
|func_footnote
|func_desc
|return_text=that is the current owner of the script

|spec
|caveats
|constants
|examples=<lsl>default
{
state_entry()
{
llInstantMessage(llGetOwner(),"Only you can hear me. Isn't that eerie.");
}

changed(integer change){if (change & CHANGED_OWNER){llResetScript();}}

}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetCreator]]|}}
{{LSL DefineRow||[[llGetOwnerKey]]|}}
{{LSL DefineRow||[[llDetectedOwner]]|}}
|also_tests
|also_events
|also_articles
|notes
|cat1=Owner
|cat2=Object
|cat3=Key
|cat4
}}

Bug triage/2008-02-11

2008-02-13T18:49:52Z

Lex Neva:

{{Bug triage}}

Next meeting: 2008-XX-XX at TIME and PLACE (FIXME). See [[Bug triage]] for details.

== Fast Track Import ==

(Move bugs here that have solid repros, or valid patches that you have reviewed)

== Hot by Vote ==

* {{jira|VWR-2123}} - Votes: 12 - Parcel name shown in menu bar does not match actual parcel information - {{User|Neo Rebus}}
* {{jira|WEB-493}} - Votes: 14 - Novice users can create issues on JIRA - {{User|Avil Creeggan}}
* {{jira|SVC-255}} - Votes: 14 - Solid, invisible ghost prims - {{User|WarKirby Magojiro}}
* {{jira|VWR-4741}} - Votes: 11 - llGiveInventoryList only delivers to agents that have been in the same sim with the script at some point in the past. - {{User|Brandon Shinobu}}
* {{jira|VWR-2999}} - Votes: 13 - Viewer Crashes after every Teleport. - {{User|Rascal Ratelle}}
* {{jira|MISC-493}} - Votes: 25 - All dialogs should have ""Ignore"" button - {{User|Marcos Fonzarelli}}

== Patches ==
* {{jira|VWR-4456}} - Votes: 0 - Do not error on gcc warning converting string to const char * - {{User|Michelle2 Zenovka}}
* {{jira|VWR-4506}} - Votes: 0 - Implement a unix make install target - {{User|Michelle2 Zenovka}}

== Misc Pool ==
* {{jira|SVC-796}} - Votes: 2 - Crashes when connecting to region upon sign on - {{User|avatar iwish}}
* {{jira|VWR-4790}} - Votes: 0 - TP freezes Viewer must Log out and relog Avatar freezes inworld on Relog forcing second Relog - {{User|sweet valentine}}
* {{jira|VWR-4779}} - Votes: 0 - Group -- Members & Roles Tab doesn't load, only effects one group - {{User|Malachi Rothschild}}
* {{jira|VWR-4509}} - Votes: 0 - ""Failed to find body part named ... in database."" - {{User|szia shilova}}
* {{jira|VWR-4384}} - Votes: 0 - Viewer Crashes As ""Connecting to Region..."" - {{User|Meghan Dench}}
* {{jira|SVC-481}} - Votes: 4 - permission sharing between scripts has been broken - {{User|Drew Dwi}}
* {{jira|MISC-922}} - Votes: 0 - Losing friends intermittantly of my list - {{User|Meaghan Winthorpe}}
* {{jira|SVC-1341}} - Votes: 0 - Mono beta: Large empty loops cause sim to stall. - {{User|davie zinner}}
* {{jira|VWR-4778}} - Votes: 0 - Items I have created with onward modify/copy perms become non mod if they contain an animation that is no mod. - {{User|ActingIll Igaly}}
* {{jira|VWR-4759}} - Votes: 0 - Prismatic rainbow color cycling on primitives - {{User|Millie Thompson}}
* {{jira|VWR-4770}} - Votes: 0 - Physics being disabled *permenantly* after enabling/disabling it multiple times via SLS (STATUS_PHYSICS, TRUE/FALSE) - {{User|Vittorio Beerbaum}}
* {{jira|VWR-3893}} - Votes: 2 - everything GLOWS with atmospheric shaders on - {{User|Lillith Anatine}}
* {{jira|VWR-2123}} - Votes: 12 - Parcel name shown in menu bar does not match actual parcel information - {{User|Neo Rebus}}
* {{jira|VWR-4727}} - Votes: 5 - 1.19.0 ( 79185 ) intermittent short freezes in client every few seconds - {{User|Dizzy Banjo}}
* {{jira|WEB-330}} - Votes: 0 - Second Life FAQ: ""Is Second Life an MMORPG"" has incorrect response. - {{User|SignpostMarv Martin}}
* {{jira|VWR-4515}} - Votes: 0 - Friends dissappaer from list - no, the other one has NOT deleted me - {{User|Rita Munro}}
* {{jira|VWR-4514}} - Votes: 0 - money request was stale...or, when buying a FREE item: [13:07] Buy object failed because you don't have enough L$. !?!? - {{User|luna fratica}}
* {{jira|SVC-721}} - Votes: 1 - Havok4 Collision Solver occasionally tosses an avatar when crossing a border over prim - {{User|Teravus Ousley}}
* {{jira|SVC-682}} - Votes: 4 - Objects can enter into No-Object-Entry area. - {{User|Nock Forager}}
* {{jira|VWR-4516}} - Votes: 0 - Atmospheric shaders go fully white/black from some angles at certain times - {{User|Haravikk Mistral}}
* {{jira|VWR-4107}} - Votes: 0 - Change the ""background"" color for textures to transparent - {{User|Domchi Underwood}}
* {{jira|VWR-4201}} - Votes: 3 - Grabbing prim with llDetectedGrab(), and dragging to the left, rotates camera left. - {{User|Sam Stork}}
* {{jira|VWR-4798}} - Votes: 0 - Quicktime Version Warning does not remove Quicktime from client memory - {{User|Ice Brodie}}
* {{jira|VWR-4791}} - Votes: 0 - Text in find and communication windows does not highlight for mac users - {{User|JamesReese Eddy}}
* {{jira|VWR-4777}} - Votes: 0 - Group IM window is labelled with resident's name instead of group name - {{User|Beeflin Grut}}
* {{jira|SVC-1144}} - Votes: 2 - replies to offline emails can't contain unicode - {{User|Lex Neva}}
* {{jira|VWR-2624}} - Votes: 0 - <select> boxes in web profile sometimes misbehave - {{User|Lex Neva}}
* {{jira|VWR-815}} - Votes: 3 - cannot change material on link sets - {{User|Lex Neva}}
* {{jira|SVC-578}} - Votes: 6 - "save object back to object contents" no longer works - {{User|Lex Neva}}

== Pre-meeting activity ==

Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.

=== Imported ===

=== Resolved ===

== Transcript ==
Transcript is/will be at [[{{PAGENAME}}/Transcript]]

== Creating An Agenda ==
{{Bug List Instructions}}

LlEscapeURL

2008-02-01T21:52:41Z

Lex Neva: touchups

{{LSL_Function
|func_id=307|func_sleep=0.0|func_energy=10.0
|func=llEscapeURL|return_type=string|p1_type=string|p1_name=url
|func_footnote
|func_desc
|return_text=that is the escaped/encoded version of '''url''', replacing spaces with %20 etc. The function will escape any character not in [a-zA-Z0-9] to %xx where xx is the hexadecimal value of the byte.
|spec
|caveats=* The function is not appropriate for escaping a URL all at once because the ': ' after the protocol and all of the '/' characters delimiting the various parts will be escaped. Instead, build the URL in parts, escaping parts of the path and query string arguments as needed.
*See: {{LSLG|string#Caveats|String:Caveats}}
|constants
|examples
|helpers
|also_functions={{LSL DefineRow|[[llUnescapeURL]]}}
|also_events
|also_tests
|also_articles={{LSL DefineRow|[[UTF-8]]}}
{{LSL DefineRow|[[Base64]]}}
|notes
|permission
|negative_index
|cat1=Encoding
|cat2=String
|cat3
|cat4
}}

Mono

2008-01-30T02:34:50Z

Lex Neva:

{{Multi-lang}}

Linden Lab Studio Icehouse is now testing a simulator upgrade which will dramatically speed the running of scripts. The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way, so all of your existing scripted objects and attachments will continue to function as before, only faster. The key to this improvement is an open-sourced virtual machine called [http://www.mono-project.com/Main_Page Mono].

Mono is now in beta. You can download a viewer which will connect you to the beta grid. Then you can teleport to a Mono region and give Mono a try yourself. Instructions at the bottom of this page.

= How LSL scripts work =
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region's simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL virtual machine.

In today's Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the LSL virtual machine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the virtual machine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.

= Enter Mono =
Mono is another kind of virtual machine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the old LSL virtual machine. But there are difficulties with switching virtual machines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono virtual machine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave 'exactly' like scripts running under the current virtual machine. It's painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new virtual machine with an assortment of tests both automated and manual.

= The Plan =
The ultimate test of the new virtual machine will be when residents can start to use Mono for their LSL scripts. Once Mono passes our internal QA we are going to deploy it to our beta grid. That grid is currently being used by Havok 4, the new version of our physics engine. However, through the wonders of Het Grid, we will be able to share the grid with Havok. Het Grid allows us to make some regions on a grid run different simulator software than others. So we can have some regions on the beta grid running Havok, and some running Mono!

We'll use the same Het Grid strategy when Mono is ready for the main grid -- initially it will be deployed only to a few regions, and residents will be able to tp over to them to confirm that their scripts still behave properly under Mono. Eventually we will release Mono gridwide and the LSL compiler will be deprecated.

= Early results =
We've run some benchmarks to compare the performance of the LSL2 virtual machine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. Once we get the beta program going we hope to get input from residents on Mono performance with more typical SL scripts.

= Mono How-to =

Suppose you have some scripts you want to test under Mono. You will need to go to a Mono-enabled region and you will need to run a Mono viewer. Step-by-step follows, also check the [[Mono beta FAQ]] if you have questions.
* Download a Mono viewer: [http://secondlife.com/community/preview.php beta viewers]
** This viewer will automatically connect you to the beta grid.
** It also contains the UI to enable compiling your script to Mono
* Launch the Mono viewer and log in as usual.
* Teleport to a Mono-enabled region of the beta grid.
** Most regions are running Havok4, not Mono
** Mono regions are:
*** Sandbox Cordova MONO
*** Sandbox Goguen MONO
*** Sandbox Newcomb MONO
*** Sandbox Wanderton MONO
* Rez the object containing the script.
* Edit the object and open the script.
* You will see a new checkbox for compiling this script to Mono instead of LSL. Check the box for Mono, then save.
** If you fail to see the checkbox, you are not running a Mono viewer.
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.
* I suggest you append the word "Mono" to the object/script name. This way you'll be able to identify which objects in your inventory will only run in Mono regions.
* Confirm that the scripted object runs the same under Mono as it has before.
** Any differences in behavior should be noted in a JIRA ticket.
** First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already
*** This may not be doable unless you've drilled down into your script to locate what is breaking.
** If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.
** If not, open a new SVC ticket for each bug you find. In the ticket summary please use the words "Mono beta" so that we can filter for them.
** In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two virtual machines.
** Link your JIRA to the meta JIRA.

= FAQ & IFAQ =
Section for questions, both frequently and infrequently asked.
; When will the Mono Beta start? : The Mono beta is in progress
; Do you have more info about the Mono Beta? : Yes, see [[Mono beta FAQ]].
; Will the available memory for scripts change? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and LSL2 bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono bytecode assets are dynamically sized. With LSL2 all scripts occupy 16k, with Mono scripts only occupy what they need.
; Will I have to manually convert all my objects to using Mono? : Yes. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono.
; Can I keep my scripts running on the old LSL2 VM forever? : We have no plans to eliminate the LSL2 VM. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support LSL2 than to migrate all scripts.
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with LSL2 for LSL scripts.
;Why didn't you use <favorite_language> instead of Mono? (ie lisp, python, lua, javascript) : TBA
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)
: No. The LSL language is not changing with this update.
; In LSL2 VM scripts are compiled on the viewer then uploaded, will that change with the Mono VM? : Yes, Mono compilation is done in a distributed fashion on the sim hosts.
; Related to the above, I use a "clever trick" to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my "clever trick" for Mono scripts? : The Mono compiler looks only at the script text. The Mono VM will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in "Script missing from database." when you try to edit them? Is there any possibility of bytecode translation, or are these scripts stuck in the LSL vm forever?

LlGetHTTPServerURL

2008-01-22T23:30:48Z

Lex Neva:

{{LSL_Function|func_id
|mode=request
|func=llGetHTTPServerURL
|func_sleep=0.0
|func_energy=10.0
|sort=GetHTTPServerURL
|return_type=string
|return_text= that is a URL identifying the HTTP server if active, empty string otherwise.
|func_desc=Returns the current HTTP server URL for the script calling the function.
|func_footer=Returned URI: <nowiki>http://sim###.agni.lindenlab.com:portofsimulator/uuid</nowiki> <nowiki>Ex: http://sim4212.agni.lindenlab.com:1337/00000000-0000-0000-0000-000000000000</nowiki>
|caveats=
|examples=<pre>
default
{
touch_start(integer t) // Touch Indicator
{
string ServerURL = llGetHTTPServerURL();
if (ServerURL != "")
{
llOwnerSay("HTTP Server URL:" + ServerURL);
}
else
{
llOwnerSay("HTTP Server Is Not Active!");
}
}
}
</pre>
|helpers
|related
|also_header
|also_events={{LSL DefineRow||[[http_request]]}}
|also_functions={{LSL DefineRow||[[llHTTPServer]]|For opening an llHTTPServer.}}
{{LSL DefineRow||[[llHTTPServerRemove]]|For removing the current HTTP server from the script.}}
{{LSL DefineRow||[[llHTTPResponse]]|For replying to HTTP requests.}}
{{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_footer
|notes=Zero Linden's Office Hours Discussion On Incoming HTTP: [https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP] PJIRA feature requests: [http://jira.secondlife.com/browse/SVC-913 SVC-913] [http://jira.secondlife.com/browse/SVC-1086 SVC-1086] Please go vote if this feature is important to you.
|cat1
}}

LlGetHTTPServerURL

2008-01-22T23:29:54Z

Lex Neva:

{{LSL_Function|func_id
|mode=request
|func=llGetHTTPServerURL
|func_sleep=0.0
|func_energy=10.0
|sort=GetHTTPServerURL
|return_type=string
|return_text= that is a URL identifying the HTTP server if active, empty string otherwise.
|func_desc=Returns the current HTTP server URL for the script calling the function.
|func_footer=Returned URI: <nowiki>http://sim###.agni:portofsimulator/uuid</nowiki> <nowiki>Ex: http://sim4212.agni:1337/00000000-0000-0000-0000-000000000000</nowiki>
|caveats=
|examples=<pre>
default
{
touch_start(integer t) // Touch Indicator
{
string ServerURL = llGetHTTPServerURL();
if (ServerURL != "")
{
llOwnerSay("HTTP Server URL:" + ServerURL);
}
else
{
llOwnerSay("HTTP Server Is Not Active!");
}
}
}
</pre>
|helpers
|related
|also_header
|also_events={{LSL DefineRow||[[http_request]]}}
|also_functions={{LSL DefineRow||[[llHTTPServer]]|For opening an llHTTPServer.}}
{{LSL DefineRow||[[llHTTPServerRemove]]|For removing the current HTTP server from the script.}}
{{LSL DefineRow||[[llHTTPResponse]]|For replying to HTTP requests.}}
{{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_footer
|notes=Zero Linden's Office Hours Discussion On Incoming HTTP: [https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP] PJIRA feature requests: [http://jira.secondlife.com/browse/SVC-913 SVC-913] [http://jira.secondlife.com/browse/SVC-1086 SVC-1086] Please go vote if this feature is important to you.
|cat1
}}

Havok4

2008-01-12T04:01:57Z

Lex Neva: "don't rez 'no copy/no transfer' items" => "don't rez 'no copy/transfer' items"; no such thing as a no copy/no transfer item.

==Havok4 (New Physics Engine) Beta Test Information Hub==
===Introduction===
The beta testing for the Havok4 implementation in Second Life is now in process. This page provides information on the project, as well as useful information that will help us all to make sure that Havok4 is tested well before it is rolled throughout the main Second Life grid.

Please read the [[Havok4 Beta1 Release Notes]]

===What Is Havok?===
The Second Life virtual world has a lot of moving parts that keep it going. One of these is the Physics Engine. A physics engine is a specialized piece of software that does the "real world" calculations to figure out what do when:
* Something or someone is pushed
* Something or someone collides with something or someone else
* Something or someone is in motion and has momentum
* Friction or damping slows the motion of something or someone

Havok is a commercially produced physics engine, and Second Life was built using Havok1. on which it operated for several years.

===How Can I Participate In Havok4 Physics Engine Testing?===
You can participate in the Beta Test of Havok4 with a few easy steps:
# Read "[[What's Changed With Havok4]]" to understand what should be different, and what should not be different, on the Havok4 Beta Test grid
# Read "[[Linkability_Rules|New Prim Linkability Rules]]" to understand how prim linkage works with Havok4 (it's better and should be much more reliable!)
# Login to the Public Issue Tracker at "[https://jira.secondlife.com/ Issue Tracker]" to see how easily you can tell us about problems you find during the beta test
# [http://secondlife.com/community/preview.php Download the install the Havok4 Beta Viewer here]

===What To Test?===
Make sure that all of the your content works on the Havok4 grid, and try as many physics-related things as you can think of as well... Here is a short list, and a link to a page with a more exhaustive list of ideas:
* Building, linking, unlinking
* Vehicles
* Weapons
* "Spells"
* Shields
* Building Tools
* Rezzing large linked sets of prims
* Try building simple and complex items, taking them into inventory and rezzing them in different orientations and in different places
* Does walking, sitting, flying, swimming, running and other avatar motions work the way you expect it to?
* Do scripts work as expected?
* Try creating scripts and modifying them
* Are permissions working correctly?
* Can you get the sim to crash using "physics crashes"? (those of you who know what this means... "go for it" and let us know if you can... ;)

There are [[Havok4_Beta_Test_Ideas|Many Things You Can Test In Havok4]] (a list of lots of things that would be helpful for you to test. Feel free to pick and choose from this list and make up your own things to try as well!

===How Do I Stay "In The Loop" With Havok4 Testing?===
# Attend "[[Regular Havok4 Office Hours In-World]]"
# TELL US about everything you find using the Public Issue Tracker at "[https://jira.secondlife.com/ Issue Tracker]" 
Please enter bugs using PROJECT "Second Life Service - SVC" and when entering the bug choose AFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" to be sure we see them right away!

===How Will Havok4 Be Tested And Rolled Out?===
This project replaces a core component of Second Life, and being sure that "anything that pushes, collides or has inertia" works right is a pretty extensive task. We have already done a lot of internal testing, and plowed through hundreds of internal bug fixes. We will be taking a phased approach to both catch as many problems as early as possible, and reduce risk of issues as Havok4 is rolled out.

Phase 1 - Internal Testing On Non-Public Test Grid (DONE!) 
We already completed this phase, and had a variety of internal staff work on Havok4 enabled simulators. Basic functions were checked, as well as checking to see that the known physics-related simulator crashes were resolved.

Phase 2 - Public Beta Test On Beta Grid ("YOU ARE HERE!" :) 
We expect the public beta test for Havok4 to be very active, with many participants. We have prepared a test grid that allows for many types of physics-related tests. The test regions will include:
* Orientation Islands
* Welcome Areas
* Lusk
* Several sandboxes
* Combat sandboxes
* Vehicle testing simulators

NOTE: The Public Beta viewer will be configured to use the beta grid, which will be a snapshot copy of portions of the main grid and a copy of your user account. You can do "anything you want" on this grid without risking damage to your "real account" on the main grid.

Phase 3 - Havok4 On A Select Few Main Grid Regions 
In this phase we will use the new HetGrid functionality to deploy Havok4 simulators on a small number of regions of the main grid. This will still be a testing phase, and for this phase any participants will need to remember that you will be on the main grid, working with your real inventory (caveat emptor - don't rez "no copy/transfer" items on these early test Havok4 sims without understanding the potential risks)

Phase 4 - Partial Main Grid Rollout (50-100 regions) 
At this point, we will have resolved outstanding issues found during beta testing and the Phase 3 "small deployment in a corner of the main grid" and will deploy Havok4 to a subset of the main grid.

After collecting feedback, if all looks good, we will continue to...

Phase 5 - Full Havok4 Rollout On Main Grid (deploy to rest of grid) 
If all is clean at this point, we will then roll out the Havok4 engine to the rest of the main grid, and we'll be "live" with Havok4 everywhere.

===A Historical Note: Why Did "Doing Havok" Take So Long?===
Some of you who have been around for a long time will know that we talked about replacing Havok1 a long time ago, and did not seem to get this project done, and finally went silent about it. After several false starts, we decided that it would be best to stop talking about the work, or making public commitments, until we were far closer to the goal, and we believe that we are finally at this point.

For "quite some time" we worked to replace Havok1 with Havok2. After working on that project, we realized that we really should rework the interfaces for how Havok is integrated with Second Life. We realized that we needed to define an abstraction layer - a layer of code that would make it easier to do future physics engine migrations so that they don't take as much effort as this migration took, and to allow for more flexibility down the road. At this point Havok4 became a much more reasonable target than implementing based on a then-older release... and thus we set Havok4 as the target. This project has been significantly larger than any of us anticipated, however the good news is that we are now here, ready for beta testing, and ready to fix the last minute issues before we bring Havok4-based sims to the main grid!

== New experiences that are normal ==

=== Ejection and separation of interpenetrating objects ===
One of the largest improvements over the previous Havok I engine is that Havok 4 supports separation of interpenetrating objects. That is, a cube that is embedded into the ground and turned physical will attempt to work its way out and up, until it has separated from from the ground and then rests on the ground.

The previous engine did not handle interpenetrating objects very well. It would go into a deeply recursive processing loop known as the "Deep Think" condition, trying to determine where the overlapping objects should move, causing the simulator to run very slowly.

The new engine quickly and easily separates overlapping objects. The objects are treated like compressed springs, so that a deeper interpenetration imparts a greater ejection force onto the object. The interpenetration resolver attempts to obey movement constraints and will not explode out through enclosing walls, but will expand out through whatever openings or spaces are available.

Here is a Google Video showing an extreme example of how the interpenetration resolver works. A stack of about 200 very large disks about 0.5 meter thick overlap in a short stack about 10 meters tall, and enclosed inside a large hollow tube. When rezzed on the ground and turned physical, the disks explode upward and out of the top of the tube, with some disks shooting over 300 meters high from the repulsive force of the overlap resolution. No scripted movements or pushes are being applied to the disks. The motion is purely from the interpenetration resolver.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Simulator lag from huge piles of stacked objects ===
Even though this is a new and improved physics engine that should not crash as frequently as the original Havok-1 engine, there are times when the new simulator will still experience very bad lag due to a large number of touching physical objects.

This lag is not a bug, and is not like the old Havok-1 Deep Think condition, but is due to a limitation in how physics engines work in general. This same problem affected Havok-1, but it wasn't as obvious, since large stacks often crashed the simulator before this condition could become apparant.

Normally when physical objects slow down to below a critical speed for a period of time, the engine quiets the physics processing for that object, in order to save CPU time for the more active objects.

In order for the physics processing to settle, the object needs to be in contact with a nonmoving reference object. A single physical bar coming to a stop touching the ground is therefore quieted.

But for multiple stacked physical objects, it is difficult for them all to settle down, because one or more of the other touching objects may still be slightly moving when the other objects settle. This slight movement of the one then reawakens the objects that previously were settled, resulting in small movements rippling through the stack. The feedback of reawakening constantly circulates through the pile so that none of them are ever really able to settle completely. This constant moving and twitching of the spheres is similar to the physical concept of Brownian Motion with atoms.

Google Video example of simulator lag generated from 565 physical spheres held inside a container:

http://video.google.com/videoplay?docid=7316931483709158462

This engine lag is not based on the size of the objects involved. A collection of 500 very small stacked objects can cause as much lag as 500 large stacked objects.

=== Thousands of objects that don't touch do not lag ===

The Havok-4 simulator will run at full speed, if there is enough space between physical objects so that the reawakening collisions are kept to a mininum.

There can be thousands of physical objects in a simulator without any lag, just so long as the objects minimally touch each other.

Google Video of 2000-3400 physical cubes in a sandbox, with no lag:

http://video.google.com/videoplay?docid=-2779779276874540721

Disc Jockey

2007-12-17T18:10:36Z

Lex Neva:

== Introduction ==

A [http://en.wikipedia.org/wiki/Disc_jockey disc jockey] or DJ is a person who selects and plays [http://en.wikipedia.org/wiki/Sound_recording prerecorded music] for an audience.

In Second Life Disc Jockeys (or DJs) are people who play music for events or venues. DJs are usually well respected and often well known because a good DJ can make an event a lot of fun and very memorable, especially if they have a great library of music and take requests.

Music (or any audio) is played in second life by configuring the Music URL in the Media tab of your land settings. Right-click your land and select "About Land..." from the menu. In the "About Land" window that pops up, select the "Media" tab. You can fill this in with your favorite music URL (for example http://160.79.128.40:7686 for oldies rock).

This URL points to a media server which broadcasts music digitally via the internet. Note, this music is sent directly to your computer, it is not handled at all by the Second Life servers.

Before you can be a DJ you need to have a media server with a URL that people can connect to. Fortunately there are several free software utilities that can do this for you. Basically you will need:

# A '''media server''' - which actually broadcasts the music
# A '''source client''' - which lets you select the music from several sources and sends it to the server.

The are many ways to set up you broadcast environment, but only one is described here in detail. Note: it can be frustrating to set up a broadcast environment because often these utilities are documented poorly, and they can be quite complex to configure properly.

== Example Broadcast Environment ==

=== Ingredients ===

# Icecast - server
# WinAmp - media player
# OddCast - source client plugin for WinAmp
# Music - files or CD you can play via WinAmp
# Computer 1 - for broadcasting
# Computer 2 - to test that you are broadcasting
# Internet Router/Gateway

This example uses

* Windows XP for Computer 1
* Windows Vista Ultimate 64 for Computer 2
* D-Link router.

but other combinations are possible.

=== Setting Up the Server ===

Install the latest version of [http://www.icecast.org IceCast] on Computer 1.

Run the IceCast user interface (in this case Icecast2.exe)

From the "Configure" menu select "Edit Configuration."

Change the following passwords in the icecast.xml file:

<authentication>

<source-password>hackme</source-password>

<relay-password>hackme</relay-password>


<admin-user>admin</admin-user>
<admin-password>hackme</admin-password>
</authentication>

for example (but select you own passwords)

<authentication>

<source-password>Play4Me</source-password>

<relay-password>Play4Me</relay-password>


<admin-user>admin</admin-user>
<admin-password>IamKing45</admin-password>
</authentication>

While this was not strictly necessary, it is always good practice to change passwords to your own secret versions.

Save you changes and close the window for the icecast.xml files.

Click the "Start Server" button.

=== Setting up WinAmp ===

Install the latest version of [http://www.winamp.com/ WinAmp] on Computer 1.

Try playing a few tunes so you can get the hang of it.

Stop WinAmp

=== Setting up the WinAmp OddCast Plug-In ===

Install the latest version of [http://www.oddsock.org/tools/oddcastv2_wa2/ OddCast] on Computer 1.

Start WinAmp again.

Under the "Options" menu select "Preferences..."

In the Preferences window select (under Plug-ins) "DSP/Effect"

In the top right of the window select "Oddcast DSP..."

The Oddcast window should open up. Click the "AddEncoder" button.

Under "Encoder Settings" right-click the encoder you just added and select "Configure" from the menu. A Configuration window will open up.

In the "Encoder Type" field, select "OggVorbis"

In the "Server Type" field, select "Icecast"

In the "Encoder Password" field type your source-password, in this case "Play4Me"

In the "Mountpoint" field type "/different.ogg"

Finally, click the "OK" button to close the Configuration Window.

In the Oddcast window click the "Connect" button.

If the server is running properly you should see the word "Connected" under the "Transfer Rate" column in the table next to the encoder you just added and configured. If it's not connected there's something wrong or your server is not running.

In the Icecast window (your opened earlier) you should be able to see 1 connection.

=== Testing the Broadcast ===

If you don't have WinAmp installed on Computer 2 do that first.

On Computer 1 start a play-list going in WinAmp - something that will be playing for a while.

On Computer 1 start WinAmp, and from the "File" menu select "Play URL".

In the "Open URL" window enter <nowiki>"http://1.2.3.4:8000/different.ogg"</nowiki> - where 1.2.3.4 is the Internet Protocol address of computer 1.

To find the IP address, go to Computer 1 and open a Command Prompt and run the "ipconfig" command. You should see something like

Ethernet adapter Local Area Connection:
IP Address . . . . . : 192.168.0.101
Default Gateway . . : 192.168.0.1

If all has gone well Computer 2 should be playing the same music that is playing on Computer 1.

If you go to Computer 1 your will see the VU meters in the Oddcast window indicating that there is music playing. From then on, any music you play in WinAmp on Computer 1 will play on Computer 2. Note: if the music stops on Computer 1, it will probably stop on Computer 2. Whey you start the music on Computer 1 again, it may not start playing on Computer 2 until you push the play button again (or something similar).

=== Testing the Broadcast on Second Life ===

Chances are your broadcast server is your personal computer at home, and it's behind a router/gateway.

The way things are set up now only computers on your personal Local Area Network can find your music broadcast, so you will have to configure your router/gateway.

Most routers have a web user interface that you can access by typing in the address of the router to your web browser. For example, from the ipconfig command discusses previously you might enter

192.168.0.1

First you will need to find the IP Address of the router that is know on the Internet. This will be published somewhere in the UI. For example, let's say it's "1.2.3.4"

Next you will need to set up a mapping to your Icecast service on Computer 1. This usually looks something like:

Application Name: icecast
IP Address: 192.168.0.101
Public Port: 8000
Private Port: 8000
Protocol: both (TCP/UDP)

where IP Address is the address of Computer 1. There may be other information. After you've saved the changes you may need to restart your router (but not usually).

Go back to Computer 2 and start Second Life. In your land, configure the following URL for you land's audio feed

<nowiki>http://1.2.3.4:8000/different.ogg</nowiki>

but don't use "1.2.3.4" - use the external address you got from your router. You should now be able to hear the music from your broadcast server on Computer 1 playing via Second Life. Anyone else on your land should also be able to hear the same music.

=== Other Settings ===

There are usually many other settings to configure and play with in your broadcast environment, such as the mount point in your URL. For example, you do not have to use "/different.ogg" in your URL, you can configure something different, such as "/rockme.ogg"

Check the documentation that comes with your utilities for extra information on configuring other settings.

== Miscellaneous ==

Often times a DJ needs to announce songs before they are played, or add other commentary. Music players like WinAmp and Source Clients like Oddcast often have way of adding input from a variety of sources, such as a microphone.

LlGetCenterOfMass

2007-02-28T17:02:37Z

Lex Neva:

{{LSL_Function
|func_id=183|func_sleep=0.0|func_energy=10.0
|func=llGetCenterOfMass|return_type=vector
|func_footnote
|func_desc
|return_text=that is the object's center of mass
|spec
|caveats
|constants
|examples
|helpers
|also_functions
|also_events
|also_tests
|also_articles
|notes
|permission
|negative_index
|cat1=Physics
|cat2
|cat3
|cat4=Stub
}}