Regarding the startup time...

I do have some additional jars, but I feel I've balanced this out by
removing several GAE jars (anything related to JDO/Datanucleus).  I'm
mostly wondering about the different times: 2 seconds vs. 15 seconds
and everything in between.  Without some consistency, I don't know how
to troubleshoot it.  I thought it had been solved at one point, but
then it returned.

Regarding being in the cloud...

Yeah, I suppose so.  I'm just wondering how to work this if
Application state can never be relied upon - in this case, the URL is
based on Application state and I'm not sure how MemCache would work.
If it were a few missing images here and there, that would be fine - a
page refresh does the trick.  But based on my experience, this will be
more frequent than not.  Oh, well - no one said it would be easy.  Is
there perhaps a way to determine the difference between an initial
request (e.g. I've clicked a link to go to a new page) and an image/
resource request required for that page?  If so, I could then restart
the entire process if the application drops in the middle.

Thanks!

Jake

On Apr 9, 3:58 am, François Masurel <[email protected]> wrote:
> Hi Jake,
>
> You're in the cloud, there is no guarantee at all that requests from
> your page will be served by the same server instance.  May be you
> should use MemCache instead of memory to store your URLs.
>
> François
>
> On 9 avr, 02:12, Jake <[email protected]> wrote:
>
> > Ok, now this is getting silly :)
>
> > My application gets a page request that contains some images.  My
> > application has some specialized logic that mounts images with
> > different states on a custom URL that is stored in the applications
> > memory - that URL is returned in the HTML.  The web browser then,
> > obviously, requests the image at the custom URL.  Unfortunately, in
> > the 3 seconds between the request for the page and the request for the
> > image, the application restarted and lost the custom URL.
>
> > Thoughts?  Is there no way to ensure that the application stays alive
> > during a complete page request?  Now that I think about it, I guess
> > there's nothing that differentiates a "complete set of page requests"
> > from a single "image" request - either of which can be a loading
> > request.
>
> > To date, this has happened at least 3-4 times - I just didn't see it
> > as a problem until an image was requested.  I'm the only traffic for
> > the time being.
>
> > Thanks!
>
> > Jake
>
> > On Apr 7, 2:52 pm, Jake <[email protected]> wrote:
>
> > > Hello,
>
> > > I'm currently using the Wicket Framework which is simply a
> > > javax.servlet.Filter.  I have a quick little logging statement in the
> > > init() method of the filter which, I believe, is the absolute first
> > > thing that should run on a loading request.
>
> > > I've been working hard to minimize the startup time for my
> > > application, but now I've discovered a delay between the initial GET
> > > request and the log statement in the init() function that is anywhere
> > > between 2 seconds and 15 seconds.  I suppose I can live with the 2
> > > seconds, but 15 seconds is pushing it :)
>
> > > 04-07 11:41AM 41.583
>
> > > 75.150.73.225 - - [07/Apr/2010:11:42:14 -0700] "GET / HTTP/1.1" 500 0
> > > - "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3)
> > > Gecko/20100401 Firefox/3.6.3,gzip(gfe)" "jacob-brookover.appspot.com"
>
> > > D 04-07 11:41AM 53.341
>
> > > org.cast.google.TestFilter init: Initializing Filter
>
> > > I've been fuddling around with a lot of things, so I'm far from a
> > > "standard" implementation at this point.  I'm hoping someone can tell
> > > me what I can do to remove such a delay.
>
> > > Thanks!
>
> > > Jake

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Reply via email to