We have tried to make the system as efficient as possible. The 10 entries/second does not seem to be too much overhead. If all 50 clients need to get all of these messages that total comes up to 500 messages/second which is probably still doable by one server but it will be pretty busy. It might be better if you can organize that into a cluster so that you can offload the delivery of messages between two servers, especially if there is a lot of other stuff going on in that server.
In terms of the overhead for subscriptions, if you use subtopics, we use hashtables to store the subscriptions so the lookup is very efficient. If you use selector expressions, we do have to test those for each unique selector expression for each message so that is more expensive. Jeff ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of changlim Sent: Wednesday, October 31, 2007 1:12 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS ManualSync and AS [Managed] Metadata Hi Jeff, Thanks for your reply. I was able to use manual sync together with HibernateAssembler custom paging to display a result set of 20,000! Real cool to see the FDS to DB paging and FDS to client paging working! As it turns out we have external service (logger) that logs exception entries into a DB table. Since this is not done via FDS I had to publish notifications into a Message channel. The Flex client would now have to subscribe and response to these event (either update data or ignore). My question is: since the exception events could be potentially very large (say 10 entries per second - a few thousand events over 24 hours, with 50 concurrent clients) how scalable is this architecture based on message queue? Is the subscription and event handling on the client expensive? Thanks, Chang --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , "Jeff Vroom" <[EMAIL PROTECTED]> wrote: > > Yes, when you use manual sync (with auto sync enabled=false) , the > client will still both detect changes made on that client and push them > to the server and receive pushed changes from the server and apply them > on that client. The difference is in how messages are routed from one > client to the next. Rather than the server tracking which data each > client is actively managing and pushing only the right data to the right > clients, you need to set up the routing rules yourself with the publish > and subscribe rules. > > > > One other difference is that the "refresh fill" process - i.e. where the > server refreshes fill methods after an insert or update or explicit > "refreshFill" call is made on the server does not work with manual sync. > Since the server has no knowledge of what fills each client is actively > managing and does not cache its current set of ids, it can't refresh it. > You can still update queries by using the > DataServiceTransaction.addItemToFill and removeItemFromFill methods. Of > course the other server side methods updateItem, createItem, and > deleteItem also still work though make sure that any use of these apis > also supply the producerSubtopics or producerDefaultHeaders needed to > route these changes to the right clients. > > > > Here's a code snippet of some client code which sets up manual > subscriptions: > > > > personService.autoSyncEnabled = > groupService.autoSyncEnabled = false; // turn off auto sync > > > > personService.manualSync.producerDefaultHeaders = > {a:"4"}; // if you use selector expressions this > is how you specify key-value pairs for the producer > > > personService.manualSync.producerSubtopics.addItem("grouptopic"); > // more commonly this publishes to a specific subtopic > > > personService.manualSync.consumerAddSubscription("grouptopic", "a IN > ('3', '4', '5')"); // subscribes both to a subtopic with a selector > expression > > personService.manualSync.consumerSubscribe(); > // this actually initiates the "subscribe" > > groupService.manualSync.producerDefaultHeaders = > {a:"4"}; > > > groupService.manualSync.producerSubtopics.addItem("grouptopic"); > > > groupService.manualSync.consumerAddSubscription("grouptopic", "a IN > ('3', '4', '5')"); > > groupService.manualSync.consumerSubscribe(); > > > > Jeff > > > > ________________________________ > > From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of changlim > Sent: Thursday, October 25, 2007 9:06 AM > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > Subject: [flexcoders] FDS ManualSync and AS [Managed] Metadata > > > > Hi All, > > I am dealing with very large data sets and is thinking of using > FDS "manualSync" (instead of <auto-sync-enabled>true</auto-sync- > enabled>) for pushing server data updates to the clients. To > use "manualSync", the client code needs to subscribe to the DataServer > for changes. From reading the FDS user guide, it was not clear to me if > FDS would be able to handle data updates for me (after the client > subscribes to the changes). > > Does having the [Managed] metadata tag in the AS class still work when > I am using "manualSync"? Or does the client now needs to provide > callback to handle updates from the manualSync channel? > > Anyone has example on how to do this? > > Thanks in advance! >
