<div dir="ltr"><div>I feel that we've transcended from this mortal coil into heavenly spheres. Such powerful realms require poetry to comprehend, so I must quote from the poem "Eloisa to Abelard":<br><br>"How happy is the blameless vestal's lot!<br>
The world forgetting, by the world forgot.<br>Eternal sunshine of the spotless mind!<br>Each pray'r accepted, and each wish resign'd;"<br><br></div>To deny failure is to deny reality.<br><div><br><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 19, 2014 at 12:43 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The point is no NOT let it fail. Asset storing never fails<br>
permanently if it's retried until successful. The upper layers (all<br>
the way to the viewer) are not equipped to handle an asset storing<br>
failure. Propagating the exception would just annoy the user with<br>
needless messages. Since asset servers can be "gone" for a while,<br>
for instance when there is a net failure, there is no way to give it<br>
a timeout, either. A sim in OSGrid, if it gets disconnected, could<br>
run on locally cached assets and manage to reconnect after 20<br>
minutes and simply upload all new assets since then. Screaming<br>
"failure" at the user is pointless in such a scenario.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 18/04/2014 22:56, Oren Hurvitz wrote:<br>
> There seems to be a misunderstanding here. We're talking about a case where<br>
> the operation has FAILED. The only question is whether to pretend that it<br>
> succeeded, so that the user will find out that it failed later, to their<br>
> surprise, or to report failure immediately. Obviously it's better to report<br>
> failure immediately.<br>
><br>
><br>
><br>
> On Fri, Apr 18, 2014 at 10:40 PM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
><br>
>> Name one valid use case where current OpenSim is able to handle such<br>
>> an exception gracefully, e.g. without user-visible error.<br>
>><br>
>> - Melanie<br>
>><br>
>> On 18/04/2014 13:28, Mike Chase wrote:<br>
>> > I'm inclined to agree with Oren. Asset Writes could fail for a variety<br>
>> of<br>
>> > reasons and there are lots of use cases where you need to know the asset<br>
>> is<br>
>> > on disk. I think propagating exceptions is the more sound approach IMO.<br>
>> ><br>
>> > I also agree re: the custom comms vs a persistent queue mechanism but I<br>
>> > don't want to derail this topic. That can wait for another day.<br>
>> ><br>
>> > Mike<br>
>> ><br>
>> > -----Original Message-----<br>
>> > From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a><br>
>> > [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Oren Hurvitz<br>
>> > Sent: Friday, April 18, 2014 7:06 AM<br>
>> > To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>> > Subject: Re: [Opensim-dev] Error detection when storing an asset<br>
>> ><br>
>> > Regarding the hiding of exceptions: to be clear, I was already bitten by<br>
>> > this behavior; that's why I started to investigate how assets are<br>
>> stored. I<br>
>> > have therefore already changed Kitely's version of OpenSim to propagate<br>
>> > exceptions, and the question is whether other people would like me to<br>
>> > contribute this change. If anyone has an opinion then please reply.<br>
>> ><br>
>> > Regarding your suggestion to save assets to local disk and retry them<br>
>> later:<br>
>> > this is basically what a persistent message queue does. If you're going<br>
>> to<br>
>> > go that route then it would be best to add a real message queue rather<br>
>> than<br>
>> > a home-grown one. I would LOVE it if OpenSim used a message queue for<br>
>> > communications, as it would allow ripping out thousands of lines of<br>
>> homemade<br>
>> > communications code, and would be faster and more reliable to boot. But<br>
>> > that's a bigger issue and I'll put it aside for now.<br>
>> ><br>
>> > In this particular case, using a persistent message queue isn't be the<br>
>> right<br>
>> > solution: the right solution is to report failures immediately. Otherwise<br>
>> > you'd get weird behavior such as a user who thinks they've successfully<br>
>> worn<br>
>> > a piece of clothing, but when they teleport to another region it<br>
>> disappears<br>
>> > because the other region can't load the asset (because it was never<br>
>> saved).<br>
>> > To prevent these problems you need to fail-fast, and tell the user<br>
>> > immediately when a problem happens. This doesn't mean to crash the sim; I<br>
>> > strongly doubt any asset failure would cause that, it would just fail the<br>
>> > specific packet or message that is currently being handled, as it should.<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > View this message in context:<br>
>> ><br>
>> <a href="http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass" target="_blank">http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass</a><br>
>> > et-tp7579223p7579225.html<br>
>> > Sent from the opensim-dev mailing list archive at Nabble.com.<br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>> ><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Oren Hurvitz<br>VP R&D<br>Kitely Ltd.<br><br>Email: <a href="mailto:orenh@kitely.com" target="_blank">orenh@kitely.com</a><a href="mailto:ilan@kitely.com" target="_blank"></a></div>
</div>