HandleSpecialURL, sessions and threads

  1. 6 years ago

    Michael B

    4 Nov 2013 Pre-Release Testers, Xojo Pro US - Pennsylvania

    Sorry if this is a re-hash of old topics but I haven't been able to figure this out from the docs or in the forums.

    I'm starting a new project which requires a web app whose sole purpose is to provide webservices for desktop client apps. I've got the following questions:
    1) Since each "service function" is going to be routed thru the HandleSpecialURL event:
    A) Does the web app automatically spawn a new thread each time this event is raised?
    B) If no automatic thread is raised, can I create my own threads from within this event where the real work will be done?
    C) OR can I create Session objects instead of threads to do the work?

    1. I'm going to use PostgreSQL as the DB - does anyone see a problem with having the App open and maintain the DB connection and pass a reference to this connection to the session or thread that does the work?
    2. Potentially there can be hundreds/thousands of simultaneous requests against this webservice - are there any scalability issues I should be aware of?
    3. I'm thinking this needs to be deployed as CGI - thoughts?

    Sorry for what may seem like beginner questions. I've done plenty of apps like this with .NET, VB and IIS but this is a first for me with Xojo.

  2. Brad H

    4 Nov 2013 Down here on the farm.
    Edited 6 years ago

    I don't know the answer to A. You could test this easily though. Build a small app with a special handler and see if it's running on the main thread. Or log the id of the thread and see if they're all different.

    As for the rest... The general rule on databases is "one connection per Session". You can't create an actual "Session" to manage your special calls, but you could create an APISession class (no super) that handles authentication and passes back a sessionId cookie or parameter so further calls can associate with the right APISession. Each APISession (a logical "api session") would maintain its own connection to your database, consistent with the general rule.

    And this is definitely not beginner stuff :-).

  3. Phillip Z

    4 Nov 2013 Pre-Release Testers, Xojo Pro Florence, SC

    Hey Michael. We are developing a product to assist with this exact use case. If you have any interest in testing it and providing feedback then email me phillip@1701software.com.

    In regards to your questions each hit is threaded. You cannot programmatically create sessions as they are deeply integrated with the javascript framework running client side. For your use case you don't really need sessions however. It sounds like you just want Xojo to thread multiple HTTP connections which HandleSpecialURL does quite nicely. If you aren't going to put a typical WE front end on this then it might make more sense to use a more bare bones HTTP server as you would have a tad more control.

  4. Phillip Z

    4 Nov 2013 Pre-Release Testers, Xojo Pro Florence, SC

    By barebones I mean something like https://code.google.com/p/realbasic-httpserver/

  5. Bob K

    4 Nov 2013 Pre-Release Testers, Xojo Pro Kansas City

    @Michael B A) Does the web app automatically spawn a new thread each time this event is raised?

    I was told by one of the Xojo engineers that a new thread is created for each event. I do NOT know if it sticks around for a bit to see if there are any additional requests from the same remote user or not. I failed to ask that question at the time. :)

  6. Michael B

    4 Nov 2013 Pre-Release Testers, Xojo Pro US - Pennsylvania

    This has all been VERY useful information. Thanks everyone!

  7. olivier v

    4 Nov 2013 Pre-Release Testers, Xojo Pro Europe (France)

    @Michael B This has all been VERY useful information.

    Yes, interesting topic, it deserves to be developed :-)

  8. Greg O

    7 Nov 2013 Xojo Inc scout.galaxy.barn

    @Bob K : Threads do not "hang around" waiting for more connections from the same client.

  9. Bob K

    7 Nov 2013 Pre-Release Testers, Xojo Pro Kansas City

    @Greg OLone @Bob K : Threads do not "hang around" waiting for more connections from the same client.

    Thanks for the clarification! I didn't know if there was a timeout or not built in.

  10. Phillip Z

    7 Nov 2013 Pre-Release Testers, Xojo Pro Florence, SC

    @Bob K Thanks for the clarification! I didn't know if there was a timeout or not built in.

    A session does die off eventually... So there has to be some internal clock somewhere that says "if javascript framework has not reported in by X time then remove all references to session."

    This would be completely behind the scenes and not related to the helper Timeout/TimedOut methods Greg mentioned.

  11. Bob K

    7 Nov 2013 Pre-Release Testers, Xojo Pro Kansas City

    Yeah, I meant I didn't know if there was a specific timeout for the threads created via the Handle Special URL. I know about the regular session timeout.

  12. Daniel T

    7 Nov 2013 Pre-Release Testers, Xojo Pro

    Parts A and C have obviously been answered. You can create your own threads as well (B). But keep in mind that Xojo is cooperatively threaded. Only one thread is actually running at a time (i.e. threads do not take advantage of multiple cores).

    @Michael B 2) I'm going to use PostgreSQL as the DB - does anyone see a problem with having the App open and maintain the DB connection and pass a reference to this connection to the session or thread that does the work?

    As Brad said, one DB connection per session is a good rule thumb. A more precise version might be one per thread if you're creating your own threads in addition to the sessions.

    3) Potentially there can be hundreds/thousands of simultaneous requests against this webservice - are there any scalability issues I should be aware of?

    If you mean there can be hundreds to thousands of "in flight" requests at any given moment, or hundreds to thousands of hits per second, then I imagine you will need to load balance across multiple WE apps, possibly running on multiple servers. Depending on the database work the same may be true of Postgres. If your requests have to be coordinated in any fashion at the Xojo level then you want to think about this and design for it from day one. This is much more challenging the moment you have to scale beyond one running app.

    4) I'm thinking this needs to be deployed as CGI - thoughts?

    That will introduce more overhead and latency.

or Sign Up to reply!