May 28, 2007

Thanks for saying thanks!

Whenever I get a question come through for the FMSguru question thingy, most always people will say "thanks for all the info you have posted" or "thanks for helping out so much" and other types of thanks messages.

Thanks is a big word to me and I appreciate it because I know that if one person steps up to say something, there are 10 more out there that have yet to say it but are thinking it (that goes for good and bad things though).

So, thanks for saying thanks when you do. It's appreciated and I'm glad I could help.

Graeme

Posted by Graeme at 01:17 PM | Comments (0)

Ask an FMS Guru #22: Does each NetConnection execute the server side script in it's own thread?

Have to apologize on the delay for this question here, I've been overwhelmed this past little bit with all kinds of work.

The question: Does each NetConnection execute the server side script in it's own thread?

The answer:

Each NetConnection does not have it's own thread, but it does stand in line in one thread that lives on the server side.

For some reason, and this has it's own pros and cons, FMS still only works on one thread on the server side per application. So, if you start up an application then a thread gets created and within that thread everything runs in the order that it is received.

This can be good in ways because you can control the order in which something will execute, but at the same time it's limiting in what you can do because you have to wait for a loop to end first or something.

So, this question actually has an explanation with it and that is that this particular person is having trouble dealing with lots of users logging into the application and making remoting calls to a DB.

Sometimes in an application you may have a lot of people do the same thing at once. Logging in is a good example. In the case where you have to do something before actually letting them do something else like accepting their connection, you can put the client in a queue. Meaning that they get placed in a lineup to wait for a return object, like from a remoting call, before they can move foward with whatever they will be doing.

So, the deal with this person is that sometimes calls would made at weird times, like there is a huge delay. At least as far as can be seen using a trace statement.

Unfortunately with FMS this can happen, but more importantly the trace may also just be delayed. I've had some tough times telling which it is.

Without looking at the code it's really hard to say what the problem could be, and the best I may be able to do is just point out that some people have noticed FMS is a bit buggy concerning making remoting calls. Sometimes it's delayed and sometimes it doesn't do anything at all. In these cases, it's best to make sure Adobe knows that you think there is a bug because they really want to know what it may be and actually fix it.

Adobe's bug reporting page is here.

Posted by Graeme at 01:08 PM | Comments (0)

May 07, 2007

Slashing subjective time from ask TOG

Here's a sorta interesting article on ask TOG. It's about subjective time.

In case you're not sure what subjective time is, it's the time that passes that has really no objective. The opposite of that being objective time of course, where when you're doing something with an objective in mind time seems to go much faster.

Anyhow, the author talks about this passage of time in relation to the internet. How when we go to sites and have to sit around while page refreshes happen that we feel like it "takes forever". The interesting thing about this article is that there is no mention at all of using flash or flex as a solution to no page refreshes and turning subjective time into objective time. Instead he only talks a bit about AJAX (and none of the cons) and prefetching through Mozilla and/or Google's services available.

Weird.. somebody needs to get this guy out of HTML only world and into one of the years of 2000. No offense of course.

Posted by Graeme at 01:19 AM | Comments (0)