[Red5] 0.7 SharedObjects... once and for all...

[Trevor Burton]

I experienced CASE 3 myself - a workaround that worked in my case was to
check on the server-side when someone disconnected whether anyone was still
connected to the SO and, if not, call so.close() - then, when the next
person connects all is well and sync events fire, etc. etc.

this may not work if you're only working client-side

T

On Fri, Aug 8, 2008 at 8:57 AM, Anze Cesar <anze.cesar at gmail.com> wrote:

> Hi,
>
> I'm running Revision: 2887 and am still having major SharedObject issues.
>
> What I need is a SO that holds an array of available streams and is updated
> by red5 on streams changes. It should be read-only for the clients.
>
> To outline them: if I create the shared object in my app start method and
> it's persistent, almost allways red5 will lock up my app. Clients that try
> to connect to that SO would be successfully connected, but disconnected some
> 30 seconds later.
>
> If the SO is not persistent, it just goes away once all clients disconnect
> from it. Which would be correct if I wouldn't have a local reference to the
> SO (I think).
> I hold a reference to it in my App adapter, as well as have a listener
> associated with it. The same thing happens even if the SO is persistent. In
> my listener I just have debug statements, and they get logged until the last
> client disconnects from the so. When the next client connects, my listener
> no longer produces any debug noise and the client just gets an empty SO.
>
> The way I solved it for now is have a sort of lazy SO creation.
> On stream publih/stream close I do:
>
> ISharedObject streamsSO = getSharedObject(scope, "streams", true);
> ...
> streamsSO.setAttribute("list", str);
>
> and on the Flex side when successfully connected I do:
> streamsSO = SharedObject.getRemote("streams",
> connection.getConnection().uri, true);
>
> which as far as I've been able to test works just fine.
>
>
>
> On Fri, Jul 4, 2008 at 11:28 AM, clemos <cl3mos at gmail.com> wrote:
>
>> Hi all
>>
>> On Thu, Jul 3, 2008 at 8:56 PM, rfkrocktk <rfkrocktk at gmail.com> wrote:
>>
>> > Case 3:
>> > Persistent SharedObject created on server-side, updated from
>> server-side.
>> > Here's where the big problems lie. Using a remote method, I can invoke a
>> > server-side change on the persistent SharedObject. The VERY FIRST time I
>> > connect to the persistent SharedObject, I can call the remote method and
>> > receive SyncEvents. My code is this:
>> "Application.pso.setAttribute("math",
>> > Math.random())" in my Red5 remote method. After I close my Flash Player
>> > instance and restart it, I receive NO SyncEvents, but I do receive my
>> > NetConnection.call's callback function telling me that the remote method
>> > worked. I also receive debug output from my server that tells me that
>> the
>> > SharedObject's property has changed according to Red5. (I just trace the
>> > value of the property via
>> > System.out.println(Application.so.getAttribute("math"))) I have also
>> tried
>> > using code such as the acquire/release and beginUpdate/endUpdate
>> functions
>> > with the server, but to no avail.
>>
>> Did you receive other exceptions or debug output ?
>> In my experience, this kind of behaviour (a SharedObject that stops
>> working when all clients have disconnected) is due to the fact (bug or
>> feature, I don't know) that SharedObjects become empty when no client
>> is connected to it, and that calling methods on it at this time will
>> throw an exception after which the SharedObject won't work properly.
>> I've been scratching my head for a while until I read the
>> org.red5.components.ClientManager source, and its "removeClient"
>> method, which shows how to prevent this effect by checking that
>> SharedObject.hasAttributes() before doing anything else on it...
>>
>> I'm not sure if it helps (it may be an over-well-known issue) and my
>> knowledge in Java is rather poor, but it's my 2c
>>
>> +++++++
>> Clément
>>
>
>
>
> --
> lp,
> Anže
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>


-- 
Trevor Burton
http://www.paperworld3d.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20080808/8b5a0bf4/attachment.html