[appengine-java] Re: Pay to Reserve JVM
The fact that the feature is called 'Pay to reserve a JVM' is interesting. Does it mean that each application runs in it's own JVM? On Nov 30, 4:57 pm, Jeffrey Goetsch jeffg@gmail.com wrote: There is a feature request to allow you to Pay to Reserve a JVM. They are wanting to see if people would be willing to pay, and how much they are will to pay. If you are interested in this feature, please vote on the ticket and comment how much you are willing to pay. http://code.google.com/p/googleappengine/issues/detail?id=2456#makech... Thanks, Jeffrey -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Why is it called Google App Engine for Java ?
On Nov 27, 7:19 pm, Diana Cruise diana.l.cru...@gmail.com wrote: Ted... java.lang.Thread, you want to launch new processes from within your app server...that's a job for URLFetch. Unlike Thread, I can't use URLFetch to perform a task asynchronously and return a result to the calling thread. -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Why is it called Google App Engine for Java ?
Actually, many people had the same reaction when GAE/J was released. See for instance, http://weblogs.java.net/blog/2009/04/16/google-app-engine-java-sucks Without a doubt if some smaller player created such an incompatible implementation they would not be allowed to call it 'Java'. On Nov 27, 7:19 pm, Diana Cruise diana.l.cru...@gmail.com wrote: As far as the naming goes, you may be the first to raise this concern in GAE's existence (2 years or so). -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Why is it called Google App Engine for Java ?
On Nov 27, 12:17 pm, Diana Cruise diana.l.cru...@gmail.com wrote: I'm curious which classes you are referring to that are missing and are NOT considered a stability risk running under a shared app server environment. Well, since you asked, java.lang.Thread is NOT a problem in most shared app server environments. The Google App Engine is 'special' in this regard. -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Why is it called Google App Engine for Java ?
Apologies, I see I didn't read the original e-mail closely. I was thinking 'shared server environment', not 'shared app server environment'. But, come to think of it, I guess whitelist is so large because GAE/J is a shared app server, not a shared server. On Nov 27, 4:22 pm, jago java.j...@gmail.com wrote: What do you mean with not a problem? On Nov 27, 10:13 pm, ted stockwell emorn...@gmail.com wrote: On Nov 27, 12:17 pm, Diana Cruise diana.l.cru...@gmail.com wrote: I'm curious which classes you are referring to that are missing and are NOT considered a stability risk running under a shared app server environment. Well, since you asked, java.lang.Thread is NOT a problem in most shared app server environments. The Google App Engine is 'special' in this regard. -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Concurrency In Transaction
On Nov 17, 10:27 pm, Rusty Wright rwright.li...@gmail.com wrote:
Ah, thanks. So if I knew how many servers my cloud is made of then I should
use that number for my MAX_RETRIES. ;-)
I'm curious about how others are handling the exceptions. The
JDOCanRetryException is subclassed by other exceptions that don't seem like
things I'd want to retry, but perhaps I don't understand the subtleties.
You are correct, you don't want to retry on any error, only the
'retry' errors.
I would write the retry method something like this...
public Object retry(final ProceedingJoinPoint pjp) throws Throwable
{
this.log.debug(called);
int retryCount = 0;
while (true) {
JDOException exception = null;
try {
return (pjp.proceed());
}
catch (final JDOCanRetryException ex) {
exception = ex;
// retry
}
catch (final JDOException ex) {
/**
* to quote Google's documentation: If any action
* fails due to the requested entity group being in
* use by another process, JDO throws a
* JDODataStoreException or a JDOException, caused by
a
* java.util.ConcurrentModificationException.
*/
if (!(ex.getCause() instanceof
ConcurrentModificationException))
throw ex; // fail
exception = ex;
// retry
}
this.log.debug(retryCount: {}, exception: {},
Integer.valueOf(++retryCount),
ExceptionUtils.getFullStackTrace(exception));
}
}
--
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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=.
[appengine-java] Re: Concurrency In Transaction
On Nov 17, 2:59 pm, Rusty Wright rwright.li...@gmail.com wrote: Is there some way to pause before retrying the database transaction? If you don't, then it seems to me that the processes that are banging into each other are going to keep failing. I'd like to add a pause for a random amount of time in the catch block. It is not necessary to pause before retrying because if a transaction fails with a 'RetryException' it is only because some other transaction was committed and that other transaction made some changes that are incompatible with the failed transactions changes. So... suppose you kick off 10 transactions at once. At *most* only 9 of those transactions will fail with a RetryException. If you retry those 9 then at *most* 8 will fail, and so on -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=.
[google-appengine] Re: Tragedy of the Commons, and Cold Starts
On Oct 24, 10:31 am, Gijsbert gijsbert.de.h...@gmail.com wrote: Does anybody know if the start time of java apps are significantly better (since they are compiled)? The Java apps also take several seconds to start. Frankly, I consider that WAY FAST. Java server-side APIs are very heavyweight and definitely designed to be started once and remain running. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Tragedy of the Commons, and Cold Starts
On Oct 22, 10:55 am, Devel63 danstic...@gmail.com wrote: Speeding up cold starts is clearly the best solution, but I don't know how much time pre-compiling would save. Paying for warm instances may help, but because anyone can auto-ping every second, the tragedy of the commons will still proceed to its inevitable conclusion, causing tremendous thrashing. Good point. I then conclude that Google *must* change the billing model for application instances from CPU time to elapsed running time if it is to avoid this tragedy of the commons. Doing so will remove the economic incentive to ping to stay warm. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Big tracker
On Oct 14, 7:05 am, Jonathan jricket...@gmail.com wrote: I looked through a couple of pages of the requests, and there are a lot of issues that I care about (and starred). There are issues there that are New from more than a year ago. How can it be that Google is taking no notice of this communication channel? I read an interestign article a few weeks ago about the culture at Google... http://www.cringely.com/2009/09/the-peoples-republic-of-google/ An interesting quote from the article... At Google I am told developers bid for what they want to do with their time. If there’s a big job to be done people commit to parts of it. And the parts nobody commits to do? They don’t get done. Really. So when we wonder exactly how a JotSpot, which I really liked, turns into a Google Sites, which I really don’t like, that morphology apparently comes from people changing what they want to change. I have no idea how true it is but it jives with what I see going on with the Google App Engine. Developers are adding new fun stuff like Task Queues and ignoring not- so-fun-stuff like fixing asynchronous URL fetch... http://code.google.com/p/googleappengine/issues/detail?id=1899 Anyway, I'm convinced that expecting Google to support the Google App Engine like it was a real business is not reasonable cause Google is just not into that. I'm keeping my eye on the Google App Engine but I'm developing for AWS. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[appengine-java] Re: Java Low Level commit timeout
On Sep 21, 1:07 pm, Jason (Google) apija...@google.com wrote: Since bulk updates to entities in the same group are performed sequentially and not in parallel - Jason Hi Jason, Question... If I do a bulk put where the entities are NOT in the same entity group then would the updates be performed in parallel?? I ask because I could put a parallel put to good use in some situations --~--~-~--~~~---~--~~ 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 google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: when will BigDecimal be supported in datastore?
On Sep 21, 3:05 am, Philippe Marschall philippe.marsch...@gmail.com
wrote:
But long is crappy abstraction. Sometimes you need two decimal places,
sometimes three, sometimes six, sometimes as many as there are.
That's all quite cumbersome to do with a long alone. String seems like
the easier way to go.
Well, in case anyone is interested, below I have included the code for
a class that can lexicographically encode BigDecimals as strings (and
I have included JUnit test class).
This class encodes numbers as strings in such a way that the
lexicographic order of the encoded strings is the same as the natural
order of the original numbers.
The length of an encoded number is only slightly larger than the
length of its original number.
Unlike other schemes, there is no limit to the size of numbers which
may be encoded.
This encoding lets you store BigDecimals as Strings and still be able
to do proper range searches in queries.
This code was based on ideas in this paper: www.zanopha.com/docs/elen.ps
, but there are some minor differences.
Feel free to use this code as you wish.
package net.sf.contrail.core.impl;
import java.math.BigDecimal;
import java.text.ParseException;
import net.sf.contrail.core.ContrailException;
/**
* Encodes numbers as strings in such a way that the lexicographic
order of the
* encoded strings is the same as the natural order of the original
numbers.
* The length of an encoded number is only slightly larger than the
length
* of its original number.
* Unlike other schemes, there is no limit to the size of numbers
which may be encoded.
*
* @author ted stockwell
*
*/
public class StorageNumberCodec {
public static final String decode(String input) {
try
{
if (input == null)
return null;
if (input.length() = 0)
return ;
return new Decoder(input)._output;
}
catch (ParseException e) {
throw new ContrailException(Failed to decode
number:+input, e);
}
}
public static final BigDecimal decodeAsBigDecimal(String input) {
try
{
if (input == null)
return null;
if (input.length() = 0)
throw new ContrailException(Internal Error:
Cannot decode an
empty String);
return new BigDecimal(new Decoder(input)._output);
}
catch (ParseException e) {
throw new ContrailException(Failed to decode
number:+input, e);
}
}
public static final String encode(String input) {
try
{
if (input == null)
return null;
if (input.length() = 0)
return ;
return new Encoder(input)._output;
}
catch (ParseException e)
{
throw new ContrailException(Failed to parse
number:+input, e);
}
}
public static final String encode(BigDecimal decimal) {
if (decimal == null)
return null;
return encode(decimal.toPlainString());
}
static public class Encoder {
private String _input;
private int _position= 0;
private int _end;
private String _output= ;
private boolean _isNegative= false;
private Encoder(String input) throws ParseException {
_input= input;
_end= _input.length();
char c= _input.charAt(_position);
if (c == '-') {
_input.charAt(_position++);
_isNegative= true;
}
readNumberBeforeDecimal();
if (readDecimalPoint()) {
readNumber(_end - _position);
}
_output+= _isNegative ? '?' : '*';
}
private boolean readDecimalPoint() throws ParseException {
if (_end = _position)
return false;
char c= _input.charAt(_position++);
if (c != '.')
throwParseException(Expected decimal point);
if (_end = _position)
return false;
_output+= _isNegative
[google-appengine] Re: Open Letter to Ryan Barrett and the AppEngine Team regarding high availability
On Sep 15, 6:04 pm, ryan ryanb+appeng...@google.com wrote: i also feel your pain in the support department. we wish we had the resources to provide more high-touch support! we're not a large team, though, so we have to ruthlessly prioritize. that often means less individual support, and it can also means prioritizing necessary but invisible internal changes over developer-visible features and bug fixes. What about opening the SDK code and accepting contributions from the community? There have been statements in the forums from Google people that eventually the SDK code would be open sourced. If you do this now I am sure that you will get bug fixes and extensions from the community (I would personally like to fix 1899, Asynchonous fetch in Java API). If you let the community help you fix issues then there will be a lot less high-touch support required from you. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 8, 2:58 pm, David Given d...@cowlark.com wrote: Adligo wrote: 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. I'm afraid not! The *only* mechanism for communicating between requests is, AFAIK (and if I'm wrong someone please correct me), memcache or the datastore. Actually, you can also use the URLFetch service to make callbacks to your application, thereby providing a thread a way to talk to another thread. This is used to good effect to parallelize queries in the asynctools project, http://code.google.com/p/asynctools/. blatant promotion of self interest Unfortunately, the Java API does not support async URLFetch like the Python API. Please go vote for async URLFetch in Java here... http://code.google.com/p/googleappengine/issues/detail?id=1899q=emorningcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component /blatant promotion of self interest --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 2, 2:34 pm, Brandon N. Wirtz drak...@digerat.com wrote: What would you need all those threads for in a web App? If you were crunching DNA, or calculating the path of particles from the big bang that would make sense... When you make an asynchronous URLFetch call does each asynchronous call to URLFetch count as a separate thread??? Suppose I want to write an app that will aggregate the search results from 30 different search engines (that's not an unrealistic real-life scenario, lots of things have to be done asynchrounously). Suppose each call to a search engine takes 1 second. Suppose I make 30 aynchronous calls to each search engine. It'll take 2 seconds for each request (cause I blew pass my thread limit on the 30th async call so I'll have to wait an extra second for that last request). And now I can only handle one user every second. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 2, 4:25 pm, Brandon N. Wirtz drak...@digerat.com wrote: Is anyone actually hitting Thread limit errors? Or is this just a typical I'm going to be the next Facebook OMG Google won't work for this when I get to 1.2m active users guess I should build my own server in my basement because it will be better, sort of naval gazing that I face with PMs and SysArc's on a regular basis? You can't break the speed of light with a Jet Engine either, but its still over kill for my soapbox derby car. Some engineers prefer to try to anticipate the problems they may run into rather than wait until the wings fall off their plane in midflight. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Datastore query performance
Since the inefficiency is in the encoding of an Entity to a Protocol Buffer should I assume that the advice to use an unindexed array instead of an unindexed List also applies to the Java environment?? On Sep 1, 6:56 am, Nick Johnson (Google) nick.john...@google.com wrote: Why do you advice using ArrayProperty instead of db.ListProperty (float, indexed=False) with the indexed=False, it should behave the same way, no ? A ListProperty requires encoding each element of the list as a separate property entry in the Entity Protocol Buffer. Protocol Buffer encoding in Python is less efficient than simple array encoding (which is extremely straightforward), and you also incur the additional overhead of serializing the key multiple times - eg, a 1000 entry list is serialized as 1000 (key, value) pairs. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[appengine-java] How to query multivalued properties in low-level Datastore API?
Hi All,
I am using the low-level Datastore API in my application.
Suppose I store a bunch of 'Recipe' entities, where each entity has a
multivalued property named 'ingredients, and the ingredients property
is a set of Strings.
For instance:
Entity recipe= new Entity(recipe, tater tot casserole);
recipe.setProperty(ingredients, new HashSet() {{
add(Tater Tots);
add(peas);
add(Cream of Celery Soup);
add(hamburger);
}});
Can I create a Query in the low-level API that will select all recipes
that include 'hamburger in the ingredients???
I'm thinking that it's possible since it's supported in the JDO API,
but I cannot see how it should be done.
Thanks in advance,
-ted stockwell
--~--~-~--~~~---~--~~
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 google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---
[appengine-java] Re: How to query multivalued properties in low-level Datastore API?
Thanks much. One more question... If I want to select recipes that have both hamburger and olives should I just add two filters??? Query query = new Query(recipe); query.addFilter(ingredients, Query.FilterOperator.EQUAL, hamburger); query.addFilter(ingredients, Query.FilterOperator.EQUAL, olives); --~--~-~--~~~---~--~~ 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 google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Memcache - how much space?
Hi Jeff, A question Can I assume that the memcache size limit will increase as the number of servers running my application increases? On Aug 10, 5:53 pm, Jeff S (Google) j...@google.com wrote: The overall memcache size limit is not set in stone so we usually don't give a hard number as whatever I say might soon be out of date. I recommend using as you need it because if your app goes over it's allotment, then the less-used data is evicted. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] The memcache service increment method is guaranteed to be atomic but is it also guaranteed to be consistent?
...in other words, is it possible for memcache to develop a 'split brain' without notifiying its clients that something bad has happened? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: The memcache service increment method is guaranteed to be atomic but is it also guaranteed to be consistent?
Actually, I meant 'coherent', not consistent. On Aug 4, 1:24 pm, ted stockwell emorn...@gmail.com wrote: ...in other words, is it possible for memcache to develop a 'split brain' without notifiying its clients that something bad has happened? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] SMS Verfication Troubles
Hi, I am in SMS Verification hell. Right now I'm in a state where if I try to verify my account I get the Too many SMS messages... error. I filled out the 'Having Trouble Receiving SMS Messages?' form here, http://appengine.google.com/waitlist/sms_issues, and I have waited two working days for a response. I really need someone to release me from my SMS Verification purgatory. Thanks in advance, -ted stockwell PS: I think I somehow got into this state because, for reasons I don't understand, it seems to have taken several hours for the SMS verification message to show up. By that time, if I try to go back to the browser and type in the verification code the browser ends up taking me back to the page to original verification page (because my web session has timed out). So, I have ended up requesting verification several times. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
