d (on the net and in printed form) on threadsafe
programming in general and synchronization in particular.
Cheers, Remigius.
On 31 Mrz., 13:51, Ice13ill wrote:
> What dies thread safe really mean ? ("your application code needs to
> use proper thread synchronization before you enable &q
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 wrote:
> I tend to agree with the previous comment by Stephen.
>
> The fact that custom clients (read non standard browsers ap
get(). This may 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,
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)"
wrote:
> I know I'm jumping late on
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 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...
>
> PKwww.g
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
be you should
also read more about 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" g
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 lo
your CI environment 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.
-
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), yo
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 ch
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 yet
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
nting
me 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 A
#x27;t
aware 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
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 s
le to execute such queries, but moreover they
execute in a reasonnable amount of time. Of course, in this particular
case it would be easier to query the entities directly using a
get(List) call, but if you have multiple referrers to query (like
an 1 to n relationship), you can't avoid this ki
to see how this
looks in Java. 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...@google
/java/datastore/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
d
possibly 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
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
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 Groups
Darshan,
Your API times being the same for both implementations suggests that
you are indeed doing the same operations in the data store.
I interpret the timings "datastore_v3.RunQuery real=122ms api=9179ms"
and "datastore_v3.RunQuery real=377ms api=9179ms" as showing
real= and api=, which also
e
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:
http://stackoverflow.com/questions/3886341/is-appengine-python-datastore-query-m
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 google-appeng...@googlegr
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,
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 wrote:
> +1
>
> No download was a feature. AND it helped people with poor practices
> learn the value of version control. :)
>
28 matches
Mail list logo