CasperVend 2/Event Vendor Script: Difference between revisions
No edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
CasperVend2 is a very efficient vendor system, and as such has always been in popular use at events, many of which consisted of packed sims of 60+ avatars. Recently, though, there have been two reported instances of CasperVend vendors not working well at two particular events - Collabor88 and Uber. | CasperVend2 is a very efficient vendor system, and as such has always been in popular use at events, many of which consisted of packed sims of 60+ avatars. Recently, though, there have been two reported instances of CasperVend vendors not working well at two particular events - '''Collabor88''' and '''Uber'''. | ||
While it has been very hard to diagnose these issues (none of our team have been able to gain access to the regions while the vendors were malfunctioning), we ''were'' able to get hold of some data from our side which has helped us identify the cause. | While it has been very hard to diagnose these issues (none of our team have been able to gain access to the regions while the vendors were malfunctioning), we ''were'' able to get hold of some data from our side which has helped us identify the cause. | ||
Revision as of 11:08, 22 September 2015
CasperVend2 is a very efficient vendor system, and as such has always been in popular use at events, many of which consisted of packed sims of 60+ avatars. Recently, though, there have been two reported instances of CasperVend vendors not working well at two particular events - Collabor88 and Uber.
While it has been very hard to diagnose these issues (none of our team have been able to gain access to the regions while the vendors were malfunctioning), we were able to get hold of some data from our side which has helped us identify the cause.
So, what's the problem?
It appears that the issue lies with HTTP-IN.
CasperVend is a very sophisticated system, which depends on complex algorithms and processes running on our servers. This is because there is simply not enough script space in the vendor itself to perform all the extensive functionality that CasperVend provides.
As part of this process, the server needs to "dial in" to the vendor - this is done to send notifications, or make payments. Unfortunately, it seems that once region load gets beyond a certain point, HTTP-IN just completely falls apart and can no longer be used, with every request failing with a message like so:
<lsl>Proxy Error
The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST http://10.9.4.70:13020/web/task/8f493d26-de0b-19f1-74c6-5d199f02a8df/script/b48999ce-5e27-5fe8-0c22-e0c03b34babc/http.
Reason: Error reading from remote server</lsl>
Once such an error has been encountered, the system automatically tries to "self-heal". This causes the vendor to reset and re-establish itself in the network. Unfortunately, in such a broken region, the vendor will take a long time to get back online.
I can't stress enough that this is an issue with Second Life and their architecture (notice the internal IP address, 10.9.4.70 is a machine on LL's internal network), and NOT a problem with CasperVend or our servers.
Why has this never been addressed before?
Quite frankly, it's never been an issue before. CasperVend has been used in huge events for many years, and while it's experienced some lag, there have never been such wide-scale issues before.
Our best bet is that something has changed recently in the LL server-side code which makes HTTP-IN more vulnerable to lag.
What is CasperTech doing about it
As usual, we are working on a "work-around", which will be made available to our customers.
The solution will be in the form of a cut-down vendor script, an "Event Vendor", which is specifically designed for malfunctioning regions like these.
This script will have limited communication capabilities, so the system will rely on other vendors rezzed elsewhere in the grid in order to process your sales. The event vendors cannot function on their own, they are merely an "end-point" for the customer. The customer will pay the event vendor, and the system will find another vendor elsewhere to actually process the transaction.
The other drawback is that we won't be able to inform the vendor about configuration changes, so when you have configured these vendors you will need to reset them using the dialog menu in order to get them to download the configuration.
The benefit of this, is that you won't lose any actual vendor functionality. Profit shares, discounts, stats, everything will still work.
We'll get this fix released as soon as possible.
It's unacceptable! I lost money! Rabble rabble!
Our role in this little relationship is to work around the problems that Second Life throws at us. The problem is not our fault, and there is no technical issue with the vending system. We are dealing here with an SL outage.
So, please direct your complaints in the direction of LL.
VideoService "youtubehd" not recognized.