and in printed form) on threadsafe
programming in general and synchronization in particular.
Cheers, Remigius.
On 31 Mrz., 13:51, Ice13ill andrei.fifi...@gmail.com wrote:
What dies thread safe really mean ? (your application code needs to
use proper thread synchronization before you enable
long lived keep-alive connections tend to exhaust thread pools on
servers that use thread pools to serve long lived keep-alive
connections.
On Mar 18, 6:57 pm, David Mora dla.m...@gmail.com wrote:
I tend to agree with the previous comment by Stephen.
The fact that custom clients (read non
Ian,
This is not true: this statement casts the result of the invocation of
get() to HashMapString, UserDetails. A cast of _cache to
HashMapString, UserDetails with subsequent invocation to get() would
look as follows:
((HashMapString, UserDetails) _cache).get(user.getInstance());
Also, the
Ikai,
Providing a real migration path for existing applications, meaning
other than work-arounds like aliases, would make such a decision
easier for owners of existing applications.
Cheers, Remigius.
On Mar 1, 9:10 pm, Ikai Lan (Google) ikai.l+gro...@google.com
wrote:
I know I'm jumping late
not deliver the correct result
(I don't know what the two methods return - but I assume the results
are different).
Cheers, Remigius.
--
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
Having no personal experience with channels so far, the only thing I
can suggest is the following small improvement:
for each channelId in list {
try { send } catch { remove the affected channel from the list }
}
See also channel wish list above...
Best regards,
Remigius.
On Feb 3, 6:59 pm
Sorry if this is a stupid question: Is there a pointer to the
prospective search/matchin API?
Cheers, R.
On Feb 5, 12:51 am, PK p...@gae123.com wrote:
Ikai:
Thanks!!! Prerelease 1.4.2 did pass our python test suite.
I look forward to seeing support for more mail API common file
types...
datastore, because it might not make sense to use
JDBC to access it.
I hope this helps even if it is not what you'd like to hear.
Cheers, Remigius.
--
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-appeng
or from
a single requests that starts multiple queued tasks. Running the test
sequentially even allows to clear the datastore between tests etc. In
any case, try not to overengineer it, keep it as simple as possible.
I hope these thoughts may help you.
Cheers, Remigius.
--
You received
Andy,
this amounts to 0.01$ (1 cent) per user per month. too high?
Moishe,
Why don't you rather think along the lines of introducing a (maybe
application specified) timeout, i.e. the token expires after there's
no successfully delivered message for a certain amount of time? This
would avoid a
LL API, Slim3 or Objectify - depending on your needs. If your data is
rather static (i.e. no variation in attributes of entities of the same
kind), you may well stick with annotated classes - meaning Slim3 or
Objectify - otherwise (i.e. attributes may vary and/or you maintain
your own metadata),
Hi Tim,
In the (current) absence of any answers by more educated people than
me, I allow myself to post to this thread.
In case you don't know, there's a sample app using channels:
http://code.google.com/p/dance-dance-robot/
http://dance-dance-robot.appspot.com/
I haven't looked at the code
Tim,
after a first glimpse on the newly published channel doc - still wet -
it looks like:
o only one client is allowed per cannel id
o no clean-up is needed
o connected clients must be tracked by the server
If you plan to create an entity per active channel in the datastore -
this could be a
Is there a code snippet around somewhere that uploads to blobstore
using URL fetch?
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send
Ian,
It does not look like there's a facility to look up queued tasks in
the task queue API. Instead you could use a heartbeat in the data
store (i.e. save an entity with a timestamp each time the task queue
task runs) that is checked by the cron job.
Cheers, Remigius.
--
You received
to the fact that the version must match the following regexp: ^(?!-)
[a-z\d\-]{1,100}$ which is even documentet... (if only I would read
all the documentation all the time!)
Cheers, Remigius.
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post
The latest is also contained in the Live URI-links that are
displayed in the versions section of the GAE admin console. I have
also noticed that at least in our case the versions are not served
(i.E. the DNS cannot be resolved, although the Live URI-link is
available, and they can also be set as
of this being possible.
Cheers, Remigius.
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr
. Of course, in this particular
case it would be easier to query the entities directly using a
get(ListKey) call, but if you have multiple referrers to query (like
an 1 to n relationship), you can't avoid this kind of query.
Cheers, Remigius.
--
You received this message because you are subscribed
. I'll keep the list posted as soon as we get any new
results.
Cheers, Remigius.
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send
give a pointer to the documentation?
thx and best regards, Remigius.
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send email to
google
/queriesandindexes.html
)
The documentation of the ll-API is a bit sparse (only the javadoc
available), and there's no mention of such a limit, but it's still a
little mystery to me why this limit should apply only for higher level
apis...
Cheers, Remigius.
--
You received this message because you
If you use a deployment script (ant, shell, whatever), you could just
add a call to a URL (pointing to your app) that is executed after
deployment instead of using cron.
If not, this may be one more reason to create one.
--
You received this message because you are subscribed to the Google
You could use a property that changes between versions and tag the
memcache entries accordingly (e.g. by using namespaces or some other
mechanism). This tag could also be used to clear the memcache contents
selectively in the above mentioned HTTP request.
--
You received this message because you
Demis,
It's the opposite: Py's data access is slower than Java's, at least
according to Darshan's experiments:
http://groups.google.com/group/google-appengine/t/7a8b716ecc8d5bb5
see also the reply in stackoverflow:
In the documentation of cron jobs (see
http://code.google.com/intl/de-CH/appengine/docs/java/config/cron.html#Cron_and_App_Versions)
it says that Cron requests are always sent to the default version of
the application.
This may be correct, but is a very short statement of what actually
happens,
Does it really help to make it configurable? Once the account is
compromised, an attacker could easily opt-in and steal the code.
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post to this group, send email to
what Robert Kluin said.
version control is a must. sources shouldn't even have to be uploaded
in the first place (or is this py only?).
On 6 Okt., 19:28, Robert Kluin robert.kl...@gmail.com wrote:
+1
No download was a feature. AND it helped people with poor practices
learn the value of
28 matches
Mail list logo
