There are innovators who "attempt" to advance the field and be the first.
They appeal to the desperate and the early adopters with nothing to loose
and much to gain.
There are guardians with deep experience who strive to ensure reliability
and predictability. They appeal to those upon whom many a
I'm still waiting on defect 2430 wrt drools. I haven't had the opportunity
yet to pull down the gae codebase and attempt to divine the root cause.
Star the defect if it's important to you.
On Nov 30, 2009 2:16 PM, "niraj" wrote:
Based on query on this forum on Drools seems like DROOLS does not
Will there be a way to separate start up activity from request activity, so
that initial requests will not be killed prematurely with a deadline
exceeded error?
On Nov 30, 2009 5:15 PM, "Toby Reyelts" wrote:
Hi Jeff,
First, it's definitely a net win for us to spin down an application if it
does
The compass solution is probably sufficient for pet projects. If I
correctly recall, there are still serious scalability issues due to the way
indexes are currently stored and restrictions on app store blob size. The
main issue is initial timeouts due to the GAE design flaw wrt startup /
initial
You might try leveraging one of the MVC frameworks which supports
inheritance for its action mapping files.
Xdoclet may be another alternative worth investigating for a lower level
build time composition of web.xml (although I haven't used it in the GAE /
Eclipse context). It was a great ant tool
Can that be clarified a bit? GAE concurrent requests are capped below 10
and 1/3 sec response time is considered a long request? This doesn't seem
realistic compared to non-trivial 3-tier JEE clusters where an installation
might support upwards of 100+ open sockets and a looong transaction might
Be wary of a try/get/catch/persist combo. I was doing this initially, but
found it triggered a memory leak. I resorted to a query by business key. I
can't confirm whats most efficient. It's certainly not in terms of index
storage overhead. I just wanted to throw out the warning.
On Dec 21, 20
The memcache is volatile without a well defined contract for expiration, so
it alone is not sufficient to support session behavior. A memcached entity
is more like a SoftReference in contract. Well a globally shared
SoftReference with, presumably, some cross JVM network serialization
overhead (t
Swap-ping from memory to cheaper persistent storage Space...whoever heard of
such a thing. (ducks)
This is where a nice, easy to find architectural whitepaper would likely
obviate such impertinent questioning.
On Jan 11, 2010 2:26 AM, "jd" wrote:
Tasks can use 30 seconds before a DeadlineExcee
