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