|
Home > Archive > Macromedia Flash Server > April 2006 > Server-side onSync handler and proxied objects
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Server-side onSync handler and proxied objects
|
|
| James Voss 2005-11-26, 5:45 pm |
| Hey folks,
I've tried for sometime to get an onSync handler working with server-side proxy shared objects. For some reason, the handler only works every once in a
while. I've used about every approach I can think of and am beginning to wonder if the problem is not just a release dependant issue for FCS. I am running
1.5 updater 2 on RedHat. I don't want to just apply updater 3 blindly as I have heard rumors of some issues and my server has been stable for a long time as
is.
Anyway, I thought I'd check and see if any of you have run into the same problem. The problem again: I don't get the onSync message in EITHER
application consitently. I will occasionally get the onSynce message in the 'client' side server app.
The scenario is this: My 'client' app connects to the 'client' server app which causes onAppStart() etc. The 'client' server app connects to the 'master' server
app which runs onAppStart and creates a shared object called siteBilling_so. When my 'client' server recieves a valid netconnection to the 'master' server, it
then creates a proxy shared object to the siteBilling_so on the 'master' server. That all works just fine and I can update the _so either directly or thru a
remote call on the netconnection object. All seems to work as it should. THe only thing that doesn't happen is neither the 'master' nor the 'client' server will
recieve the onSync call. Except if I reload all apps and start everything up again, maybe once in 5 - 8 times the onSync will work. When they work, they
work fine.
Here is some cut and paste of my code. Essential it is exactly the code from 'programming flash communication server' by orielly books.
************ Here is the 'client' server code ******************
NOTE: this happens in main.asc application.onAppStart() in the 'client' server which is connecting to another app that is the 'master' server.
if(info.code = "NetConnection.Connect.Success")
{
application.siteBilling_so = SharedObject.get("siteBilling", false, application.SOS_nc);
application.siteBilling_so.onSync = function(list)
{
trace("----dev-chat - 2 onSync list.length: " + list.length + " ----");
******************** Here is the 'master' server code ***************************************
application.onAppStart = function() {
trace("Loading sos.asc shared object server v1.0");
trace("Application name : " + application.name);
// The siteBilling_so holds ALL of the billing info for a given siteID
this.siteBilling_so = SharedObject.get("siteBilling", false);
this.siteBilling_so.onSync = function(list)
{
trace("----onSync list.length: " + list.length + " ----");
}
Thanks for any help,
James Voss
Ultimate Web Forums
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-11-27, 7:45 am |
| Stab in the dark: when you say it all works fine except you don't see
onsyncs: could it be that they do work as expected but you simply aren't
'there' at the right time to see the trace output?
This type of app is very hard to debug. I usually work using 3 app
inspectors: one for master, one for app instance and one where I can unload
both apps. Once both apps are unloaded (with view still on the live log) I
connect my swf. This enables me to see all the startup traces.
One common problem with this setup is that app connects to master and as
soon as it's got a success it tries to update the SO - but the SO may not
yet be synced up.
The first connection to the app needs to be handled in a special way, you
must make sure that you aren't updating the SO until its synced up.
Hard to explain but I HTH
Stefan
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of James Voss
> Sent: 26 November 2005 21:17
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> Subject: [FlashComm] Server-side onSync handler and proxied objects
>
> Hey folks,
>
> I've tried for sometime to get an onSync handler working with server-side
> proxy shared objects. For some reason, the handler only works every once
> in a
> while. I've used about every approach I can think of and am beginning to
> wonder if the problem is not just a release dependant issue for FCS. I am
> running
> 1.5 updater 2 on RedHat. I don't want to just apply updater 3 blindly as I
> have heard rumors of some issues and my server has been stable for a long
> time as
> is.
>
> Anyway, I thought I'd check and see if any of you have run into the same
> problem. The problem again: I don't get the onSync message in EITHER
> application consitently. I will occasionally get the onSynce message in
> the 'client' side server app.
>
> The scenario is this: My 'client' app connects to the 'client' server app
> which causes onAppStart() etc. The 'client' server app connects to the
> 'master' server
> app which runs onAppStart and creates a shared object called
> siteBilling_so. When my 'client' server recieves a valid netconnection to
> the 'master' server, it
> then creates a proxy shared object to the siteBilling_so on the 'master'
> server. That all works just fine and I can update the _so either directly
> or thru a
> remote call on the netconnection object. All seems to work as it should.
> THe only thing that doesn't happen is neither the 'master' nor the
> 'client' server will
> recieve the onSync call. Except if I reload all apps and start everything
> up again, maybe once in 5 - 8 times the onSync will work. When they work,
> they
> work fine.
>
> Here is some cut and paste of my code. Essential it is exactly the code
> from 'programming flash communication server' by orielly books.
>
> ************ Here is the 'client' server code ******************
>
> NOTE: this happens in main.asc application.onAppStart() in the 'client'
> server which is connecting to another app that is the 'master' server.
>
> if(info.code = "NetConnection.Connect.Success")
> {
> application.siteBilling_so =
> SharedObject.get("siteBilling", false, application.SOS_nc);
> application.siteBilling_so.onSync = function(list)
> {
> trace("----dev-chat - 2 onSync list.length:
" +
> list.length + " ----");
>
>
> ******************** Here is the 'master' server code
> ***************************************
>
> application.onAppStart = function() {
> trace("Loading sos.asc shared object server v1.0");
> trace("Application name : " + application.name);
> // The siteBilling_so holds ALL of the billing info for a given
> siteID
> this.siteBilling_so = SharedObject.get("siteBilling", false);
> this.siteBilling_so.onSync = function(list)
> {
> trace("----onSync list.length: " + list.length + " ----");
> }
>
>
>
> Thanks for any help,
>
> James Voss
> Ultimate Web Forums
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| James Voss 2005-11-27, 5:45 pm |
| thanks Stefan,
I have been testing as you suggested and I have confirmed the following:
I have two apps, one we will call 'master' and the other 'node'. onAppStart, 'node' opens a netConnection to 'master', waits for the nc.connect.success
message, then creates a proxy sharedObject using the nc to 'master' and waits for the SharedObject.Proxy.Connect message.
All of that works just fine and I can see all of the messages in the traces as well as see the objects via my FCS admin panels. Maybe 30% of the time, at the
end of this sequence, I will recieve an onSync message in my 'node' application. IF I recieve this onSync, then I will recieve every onSync for as long as I
run my app. If I don't recieve the first onSync, I will never receive an onSync.
I am being very careful to not access the shared object on either the 'master' or the 'node' app until after I have received the first onSync. I have also
checked to make sure that I am able to access the data in the _so from both servers and have no problem doing that. The data is updated no matter which
server changes it.
I have used a nc.call from the 'node' to the 'master' and allowed only the 'master' to push data into the _so. Still the pattern holds true. IF, IF, IF... I recieve
the first onSync, the all works fine, otherwise, I never receive an onSync.
Anyway, what I've decided to do is put this on hold for a while and work around this issue by just using the nc.call to post data to the _so. That will work
fine for this version of the code, but later I will need to solve it so that the _so works as it should.
Once I get this version rolled out, I will revisit this problem using a small app designed ONLY to test this issue so that I can be certain of no other code
interference.
FCS version 1.5.2 r138
RedHat Linux
Thanks again for the help,
James
On Sun, 27 Nov 2005 12:33:47 -0000, Stefan Richter wrote:
>Stab in the dark: when you say it all works fine except you don't see
>onsyncs: could it be that they do work as expected but you simply aren't
>'there' at the right time to see the trace output?
>This type of app is very hard to debug. I usually work using 3 app
>inspectors: one for master, one for app instance and one where I can unload
>both apps. Once both apps are unloaded (with view still on the live log) I
>connect my swf. This enables me to see all the startup traces.
>One common problem with this setup is that app connects to master and as
>soon as it's got a success it tries to update the SO - but the SO may not
>yet be synced up.
>The first connection to the app needs to be handled in a special way, you
>must make sure that you aren't updating the SO until its synced up.
>Hard to explain but I HTH
>Stefan
>" +
[vbcol=seagreen]
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Dario De Agostini 2005-11-28, 7:45 am |
| hi James,
i'm not going to help you... i'm writing just to say that (like i said
some times in this list) i found out the EXACT same behaviour you found.
Proxied shared object (on linux) simply won't work sometimes...
It is exactly like you describe it... they will work just sometimes...
if you keep reloading your applications... sometimes they will sync...
sometimes they won't...
like Stefan said you might think it's a problem regarding the order you
send commands... or the fact you try to instantiate objects/commands
BEFORE everything is ready.
But it's not!
you can reproduce this behaviour with simple applications too...
we found NO solution to this. (and reported this as a bug, 1 year ago...
never got any answer)
we were using suse enterprise on "client-fcs" and win2k on master-fcs.
I will have to look at the problem soon (less than 1 month), i hope to
find a way to solve this (especially beacuse we can't use FMS2 due to
the licensing of origin/edge solution, which works fine) but i'm not
sure there is one solution to this problem.
Dario De Agostini
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-11-28, 7:45 am |
| Thanks James,
please keep us posted on this one. Many people on this list have had issues
with proxySOs at one time or another.
I too re-wrote an application because of proxySOs behaving unexpectedly.
Stefan
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of James Voss
> Sent: 27 November 2005 19:20
> To: FlashComm Mailing List
> Subject: RE: [FlashComm] Server-side onSync handler and proxied objects
>
> thanks Stefan,
>
> I have been testing as you suggested and I have confirmed the following:
>
> I have two apps, one we will call 'master' and the other 'node'.
> onAppStart, 'node' opens a netConnection to 'master', waits for the
> nc.connect.success
> message, then creates a proxy sharedObject using the nc to 'master' and
> waits for the SharedObject.Proxy.Connect message.
>
> All of that works just fine and I can see all of the messages in the
> traces as well as see the objects via my FCS admin panels. Maybe 30% of
> the time, at the
> end of this sequence, I will recieve an onSync message in my 'node'
> application. IF I recieve this onSync, then I will recieve every onSync
> for as long as I
> run my app. If I don't recieve the first onSync, I will never receive an
> onSync.
>
> I am being very careful to not access the shared object on either the
> 'master' or the 'node' app until after I have received the first onSync. I
> have also
> checked to make sure that I am able to access the data in the _so from
> both servers and have no problem doing that. The data is updated no matter
> which
> server changes it.
>
> I have used a nc.call from the 'node' to the 'master' and allowed only the
> 'master' to push data into the _so. Still the pattern holds true. IF, IF,
> IF... I recieve
> the first onSync, the all works fine, otherwise, I never receive an
> onSync.
>
> Anyway, what I've decided to do is put this on hold for a while and work
> around this issue by just using the nc.call to post data to the _so. That
> will work
> fine for this version of the code, but later I will need to solve it so
> that the _so works as it should.
>
> Once I get this version rolled out, I will revisit this problem using a
> small app designed ONLY to test this issue so that I can be certain of no
> other code
> interference.
>
> FCS version 1.5.2 r138
> RedHat Linux
>
> Thanks again for the help,
>
> James
>
>
> On Sun, 27 Nov 2005 12:33:47 -0000, Stefan Richter wrote:
>
>
> unload
> I
>
>
>
>
>
>
> side
> once
> to
> am
> as I
> long
> same
> app
> to
> 'master'
> directly
> should.
> everything
> work,
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| James Voss 2005-11-28, 5:54 pm |
| Thanks Dario,
Your answer actually does help. A lot in fact. Now at least I know I'm not (compeletly) crazy.
I'll make use of the nc.call capabilities for now.
Agreed, the new pricing structure, at least as it now stands, is really going to lay waste to a lot of business models.
Thanks,
James
On Mon, 28 Nov 2005 10:01:26 +0100, Dario De Agostini wrote:
>hi James,
>i'm not going to help you... i'm writing just to say that (like i said
>some times in this list) i found out the EXACT same behaviour you found.
>Proxied shared object (on linux) simply won't work sometimes...
>It is exactly like you describe it... they will work just sometimes...
>if you keep reloading your applications... sometimes they will sync...
>sometimes they won't...
>like Stefan said you might think it's a problem regarding the order you
>send commands... or the fact you try to instantiate objects/commands
>BEFORE everything is ready.
>But it's not!
>you can reproduce this behaviour with simple applications too...
>we found NO solution to this. (and reported this as a bug, 1 year ago...
>never got any answer)
>we were using suse enterprise on "client-fcs" and win2k on master-fcs.
>I will have to look at the problem soon (less than 1 month), i hope to
>find a way to solve this (especially beacuse we can't use FMS2 due to
>the licensing of origin/edge solution, which works fine) but i'm not
>sure there is one solution to this problem.
>Dario De Agostini
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Beto A 2005-11-28, 5:54 pm |
| Has anybody got a progress report on Steve or Chris for licensing??
=20
Are we back out in the cold? I have sent a couple of emails off list w=
ith no reply...maybe they are too busy straightening things out... gettin=
g it right usually takes longer right???? *fingers crossed*
=20
cheers
James Voss <jvoss-kXB7xIAHHG2Wudb1jGF6pJqQE7yCjDx5@public.gmane.org> wrote:
Thanks Dario,=20
Your answer actually does help. A lot in fact. Now at least I know I'm no=
t (compeletly) crazy.
I'll make use of the nc.call capabilities for now.
Agreed, the new pricing structure, at least as it now stands, is really g=
oing to lay waste to a lot of business models.
Thanks,
James
On Mon, 28 Nov 2005 10:01:26 +0100, Dario De Agostini wrote:
>hi James,
>i'm not going to help you... i'm writing just to say that (like i said=20
>some times in this list) i found out the EXACT same behaviour you found.
>Proxied shared object (on linux) simply won't work sometimes...
>It is exactly like you describe it... they will work just sometimes...=20
>if you keep reloading your applications... sometimes they will sync...=20
>sometimes they won't...
>like Stefan said you might think it's a problem regarding the order you=20
>send commands... or the fact you try to instantiate objects/commands=20
>BEFORE everything is ready.
>But it's not!
>you can reproduce this behaviour with simple applications too...
>we found NO solution to this. (and reported this as a bug, 1 year ago...=
=20
>never got any answer)
>we were using suse enterprise on "client-fcs" and win2k on master-fcs.
>I will have to look at the problem soon (less than 1 month), i hope to=20
>find a way to solve this (especially beacuse we can't use FMS2 due to=20
>the licensing of origin/edge solution, which works fine) but i'm not=20
>sure there is one solution to this problem.
>Dario De Agostini
>=3D-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=3D-----------------------------------------------------------
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=20
=09
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Maulik Kataria 2006-04-24, 7:59 am |
| Yeah proxied SO has that nature... either PSO works all fine or never works
(not a single onsync after .connect.success message)
Does this happens in FMS2 also ? Actually we will be developing on
FCS1.5only but in case it is fixed in FMS2 we can think over it...
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
|
|
|
|
|