|
Are you using RTMP? Are you
using the data management services or just doing this all via remote object?
If you are using RTMP, by default, there
is an idle subscription timeout on the channel of 20 minutes. At
this point, the client should receive a fault event and though it should
auto-connect on the next attempt, it will be in a new FlexSession. Maybe
there is some reason this process is not working properly? You can
set this timeout to a small value (say 1 minute) for your testing to see if
leaving the application idle for that time will reproduce the problem in your
testing environment. If not, I’d turn on some debug logging and get
a big trace file of the activity so you can go back and figure out what is
happening when a user reports that some data did not get saved (make sure you
are logging the user’s name so you can find the trace of their activity).
Possibly there is an exception or something when committing the
transaction which is being swallowed someplace? Typically an error
which would cause a failure to save some data would be propagated up to the
user level and as a fault event so also make sure you are trapping fault events
at the client level. Here is more info on session timeouts if
you think that could be causing the problem (this is from a response to an
earlier question) which might be helpful too. ---- There are actually three timeout settings
you may need to configure for FDS. There is the HTTP session timeout
which is configured via your app server’s settings. That controls
the session timeout for HTTP based channels as you would expect. Any
activity on the session for that web application will keep that session alive.
This includes the polling requests which are initiated by that client so
if your polling interval is more frequent than your app server’s session
timeout, your session will be kept alive. There is the idle-timeout-minutes
attribute for RTMP channels which determines the session timeout for RTMP based
channels. Any message sent or received over the channel will keep it
alive. This will timeout if the connection is left idle. There is also the subscription timeout
which you set for a given destination via the (poorly named) session-timeout
tag underneath the network tag for that destination. If you set this to
0, the subscription timeout is the same as the session timeout.
This is not the default though… It defaults to 20 minutes.
When this timeout expires, it sends a message to the client which
tells it to unsubscribe from the channel. When a consumer
unsubscribes, it also disconnects from the channel. So with the
default session-timeout, a client which subscribes even using an AMF polling
channel will get unsubscribed automatically which will stop the polling.
That will allow the HTTP session to expire normally. If you are using Data Management Services
and your destination is unsubscribed due to the subscription timeout, it causes
your DataService to be disconnected. You can watch for properties change
events on the “connected” flag or bind to that property on the
DataService. If you are using the default you can watch
for the connected property on your DataService to be set to false. Any
message like fill, getItem, or commit which you invoke on the DataService will
cause it to reconnect automatically. When you reconnect, the
DataService automatically resubscribes for any fills, getItems or whatever
which you have not explicitly released. Jeff From: Hey everyone, -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___ |
