Hi All,

   Ok this is all very interesting, and in a nut shell GAE isn't true
J2EE impl.  So now I am wondering;
Is there a way to tell if my servlet is running on GAE?

This may seem like a really stupid question, however if you think
about it a little from my point of view IT's NOT. The reason I am
asking it is because I am trying to write Components (Server and Client
[browser] side), which are for sale.  So I may not be the one
installing some of these Components, and it would be nice if the
Component could simply figure out if it was running on GAE.  Otherwise
I will need to put some configuration settings in place;
Something like
web.xml
.... isGae=true
     isGae=false

Cheers,
Scott

On Sep 9, 5:24 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
> Hi Adligo,
>
>
>
> On Tue, Sep 8, 2009 at 6:39 PM, Adligo <sc...@adligo.com> wrote:
>
> > Hi Nick,
>
> >   Please see below;
>
> > On Sep 4, 10:04 am, "Nick Johnson (Google)" <nick.john...@google.com>
> > wrote:
> > > Hi Adligo,
> > > App Engine is not really designed for 'long polling' setups like you
> > > describe. Since the number of simultaneous runtimes your app has at a
> > given
> > > traffic level is limited, waiting like this will consume them all very
> > > quickly.
> > I understand this, which is why I was asking if you could pay for
> > more.
> > So can you?
>
> No. As stated, this is not something App Engine is designed to support, and
> thus your number of concurrent requests is limited proportional to the
> traffic your app gets.
>
>
>
>
>
> > > Also, because your app may be distributed over many computers, a
> > > synchronization primitive like the one you're using will not work - the
> > > process doing the notifying may not be on the same machine as the
> > > process(es) that need notifying!
> > Well this depends a little on Session management, the
> > ArrayBlockingQueue
> > I mentioned is stored as a Session Attribute.  I assume that the app
> > engine must be
> > keeping the Session in a location that can be accessed by all
> > threads.  Otherwise how
> > could anyone maintain any sort or security on the server side (most
> > Jaas HttpFilters I have seen store the Subject[User] as a Session
> > Attribute, including 2 that I wrote by hand for custom requirements
> > and Spring security) ?
>
> The issue is not multiple threads on one runtime, but the fact that a single
> App Engine app may be running on multiple runtimes, on multiple separate
> machines. You cannot expect a standard locking primitive to function across
> multiple machines.
>
> Or in other words how does the app engine treat HttpSessions and their
>
> > attributes, in the normal J2EE way, or some other way?
>
> Sessions are stored in the datastore.
>
> -Nick Johnson
>
>
>
>
>
> > Cheers,
> > Scott
>
> > > -Nick Johnson
>
> > > On Thu, Sep 3, 2009 at 9:06 PM, Adligo <sc...@adligo.com> wrote:
>
> > > > Hi Nick,
>
> > > >   I am not calling sleep but I am using a server side
> > > > ArrayBlockingQueue, with methods like
> > > > queue.poll(waitTime, TimeUnit.SECONDS);
> > > >  So I am not buffering but simply responding with current messages
> > > > and if there arn't any waiting until some show up and then
> > > > responding.  If no messages show up in 20 seconds or so I respond with
> > > > a empty message list and then the client sends a new request.
>
> > > > I am using GWT's rpc, here is my service api, which is open souce.
>
> > > >http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/.
> > ..
>
> > > > So I am anticipateing that I will have a lot of threads that are
> > > > simply waiting on the ArrayBlockingQueue's poll method.  This allows
> > > > me to do things like;
> > > > 1) send log messages between two browser windows
> > > > 2) send system messages from a admin console to anyone viewing the app
> > > > like;
> > > >      (System is going off line in 10 minutes)
> > > >      (There is pizza in the lobby for anyone who wants it)
> > > >      exc
> > > > 3)  Implement a IM client in the browser
> > > > 4) Send 'event' data between browser windows so a user can click a
> > > > button in one window
> > > >     and have it do something to another window.   Currently the only
> > > > application of this is to
> > > >    reload the adligo_log.properties file, so you can change your log
> > > > levels at runtime.  However
> > > >    there are a lot of other applications for this, windows can now
> > > > communicate.
>
> > > > Also there shouldn't be much of a drain on the processor, since most
> > > > of the threads are simply waiting (not doing a lot of processing).  It
> > > > just requires a large number of threads (one per browser window).
>
> > > > Cheers,
> > > > Scott
>
> > > > PS I would really like to host on Google Apps, the server
> > > >http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true
> > > > was down all morning, since I had my phone turned off to respect for a
> > > > concert last night I didn't get a 'your server is down' text from
> > > > hosttracker.com.
>
> > > > On Sep 3, 3:51 am, "Nick Johnson (Google)" <nick.john...@google.com>
> > > > wrote:
> > > > > Hi Adligo,
> > > > > The limit on concurrent instances of your app is not a hard one - it
> > will
> > > > > increase as your app gets more traffic. The only situation you're
> > likely
> > > > to
> > > > > run into it is if you have a lot of requests that take a long time to
> > > > > complete - eg, if you're calling time.sleep() in your request
> > handler. As
> > > > > long as you're serving your requests reasonably efficiently, you can
> > > > expect
> > > > > the number of concurrent requests your app is allowed to scale up
> > with
> > > > load.
>
> > > > > -Nick Johnson
>
> > > > > On Wed, Sep 2, 2009 at 1:33 AM, Adligo <sc...@adligo.com> wrote:
>
> > > > > > Hi,
>
> > > > > >   I am developing a app (or more than one) that I would like to
> > host
> > > > > > on Google App Engine, however the architecture of the app involves
> > > > > > cranking up the maxThreads (I am using my home grown hosting which
> > now
> > > > > > has Tomcat set to 2,000 maxThreads :) ).
>
> > > > > > For example (1 six+ year old machine in my basement)
>
> >http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true
>
> > > > > > I was reading somewhere that my app will be limited to 30 Max
> > > > > > simultaneous requests (maxThreads), and I didn't see anything about
> > > > > > being able to change this (EVEN IF YOU PAY FOR IT).
>
> > > > > > So is it possible to change this?
> > > > > > If not why, it should be billable like everything else...
> > > > > > How much would it cost?
>
> > > > > > Also I think that it seems like a silly limit (although probably a
> > > > > > good starting point for most apps).   Some apps need a lot of
> > threads,
> > > > > > some have a lot of page requests.
> > > > > >    For instance my app needs a lot of threads (the above version
> > uses
> > > > > > at least 1 per user ALL THE TIME) and will go to 2 per user in the
> > > > > > next release :) Or rather to be more specific One thread per open
> > > > > > browser window, so I can 'send' data to the browser window in near
> > > > > > real time with out having the browser window send a request every
> > > > > > millisecond (which causes other problems).
> > > > > > So it will be limited to 15 users on Googles App Engine yikes!
>
> > > > > > Cheers,
> > > > > > Scott
>
> > > > > --
> > > > > Nick Johnson, Developer Programs Engineer, App Engine- Hide quoted
> > text -
>
> > > > > - Show quoted text -
>
> > > --
> > > Nick Johnson, Developer Programs Engineer, App Engine- Hide quoted text -
>
> > > - Show quoted text -
>
> --
> Nick Johnson, Developer Programs Engineer, App Engine
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to