Ah, check. I'm going to check on that, as I don't think it's a quota,
it's a scaling factor. My apps on my own load balancing
infrastructure can't do better - if I put more threads up, I still
start to incur more latency because of context-switching costs. I
think it's a warning that if you are serving more than that
simultaneously, then you'll start to incur extra latency which,
because of quotas and billable services, may actually cost you money.
But I'd have to confirm that.
Christian
On 17-Apr-09, at 12:58 , Fernando Padilla wrote:
Cool. I think this conversation is probably over.. as to let's wait
one week to see what Howard comes up with..
But let me clarify what I was talking about:
I am talking about concurrent requests (which in my mind translates
to # of request handler threads in tomcat or jetty). And the number
of concurrent users you can actually handle depends on how long your
requests take to process.. Which depends on how complicated or data
intensive your site is, etc etc..
At the bottom of http://code.google.com/appengine/docs/java/runtime.html
"simultaneous dynamic requests 30 *"
"* An application can process around 30 active dynamic requests
simultaneously. This means that an application whose average server-
side request processing time is 75 milliseconds can serve up to
(1000 ms/second / 75 ms/request) * 30 = 400 requests/second without
incurring any additional latency. Applications that are heavily CPU-
bound may incur some additional latency in long-running requests in
order to make room for other apps sharing the same servers. Requests
for static files are not affected by this limit."
Christian Edward Gruber wrote:
You're not allowed to have any concurrent threads. What do you
mean? Concurrent requests? There's 30 seconds max response on
those. There's 10 cron jobs available... I'm confused. The docs
say: "The total number of requests to the app. The per-minute
quotas for application with billing enabled allow for up to 500
requests per second--more than one billion requests per month. If
your application requires even higher quotas..." and the free
daily quota for requests, divided into per-minute is: "7,400
requests/minute". So I'm not sure as to what you're referring.
The quote info is here: http://code.google.com/appengine/docs/quotas.html
Having said all that, you're right - there's no actual requirement
that T5.1 support a beta "early look" software. The only reason I
think it's an issue is that 5.0.x seems to work, so there's some
frustration at play among those who have already upgraded to T5.1
who want to also be GAE users. Super-awesomely-critical? Probably
not. Just frustrating.
Christian.
On 17-Apr-09, at 12:34 , Fernando Padilla wrote:
Don't forget right now GAE/Java is really really beta. You are
only allowed to have 30 cuncurrent threads? Unless your app is
only serving a small number of users, I can't vote to use GAE/Java
for actual production apps, not yet..
And like someone just said, this just came out a week ago. GAE/
Java is not a priority feature in this landscape, not yet..
Maybe after a month, if Tapestry is still not working in GAE/Java,
then start ratcheting up the pressure and complaints.. sorry.
So I guess if it's really really important for you, you won't be
able to upgrade to 5.1 for a few more weeks.. sorry.
Alex Kotchnev wrote:
I'm not sure about everyone else, but for me this is a BIG issue
and
is one of the reasons holding me back from moving my app to the 5.1
beta. Most likely I'll hold off on upgrading to 5.1 final if it
doesn't support GAE.
Howard was asking earlier about any showstoppers preventing 5.1
from
moving forward - this is one for me. Maybe this would be a good
feature for 5.2, who knows. Is anyone else holding off on taking up
5.1 for this reason ? Other reasons ?
Cheers,
Alex Kotchnev
On Thu, Apr 16, 2009 at 3:44 PM, Christian Köberl
<tapestry.christian.koeb...@gmail.com> wrote:
I grepped over the tapestry-core sources for "javax.xml.stream"
and only
found them imported in TemplateParser and StaxTemplateParser.
Would it then be sufficient to just contribute another
TemplateParser which
isn't using Woodstox (maybe the one from 5.0.1.8)?
I just tried to eliminate Woodstox and to use "pure" Stax API
for template parsing. This wasn't that difficult (see http://derkoe.wordpress.com/2009/04/16/tapestry-51-woodstox/)
.
With plain Stax I still get the same error in TemplateParser.
Maybe I will try to switch back to the 5.0.18 one when I have
time.
Cheers,
Chris
--
View this message in context:
http://n2.nabble.com/Java-support-added-to-Google-AppEngine-tp2605876p2643391.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
