Allow prioritisation of memcache data [35885112]

Assigned

Feature Request

Status Update

No update yet.

Description

ha...@gmail.com

created issue #1

Jun 30, 2009 07:02PM

This feature request is being raised in response to the discussion in this
thread

http://groups.google.com/group/google-appengine/browse_thread/thread/b02ad0016e6ac7f3/97c3f245b60128a2

Please provide a means to indicate the priority of memcache data, such that
higher priority data is never evicted by lower priority data.

One way to implement this is to provide a separate memcache instance for
every supported priority level. See the discussion link above for more detail.

Note that currently developers choose not to cache certain data for fear
that other, more important data may be evicted. This increases CPU and
datastore load. It seems providing the ability to prioritise memcache data
has very few downsides (perhaps a slight reduction in memory utilisation),
and many upsides (a more efficient GAE, with more CPU and more datastore
cycles available).

Please also provide memcache stats in admin console for each priority level.

Comments

bt...@brandonthomson.com <bt...@brandonthomson.com> #2Sep 18, 2009 03:18PM

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

we...@google.com <we...@google.com> Jan 29, 2010 10:42PM

Assigned to we...@google.com.

jo...@gmail.com <jo...@gmail.com> #3Apr 29, 2010 03:51PM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

[Deleted User] <[Deleted User]> #4Aug 18, 2010 02:13AM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

ha...@gmail.com <ha...@gmail.com> #5Aug 18, 2010 06:16PM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

ad...@gmail.com <ad...@gmail.com> #6Dec 23, 2010 10:45PM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

wp...@gmail.com <wp...@gmail.com> #7May 10, 2011 11:21AM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

pr...@google.com <pr...@google.com> #8Aug 27, 2011 12:49AM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

bt...@brandonthomson.com <bt...@brandonthomson.com> #9Jan 29, 2012 12:25AM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

wp...@gmail.com <wp...@gmail.com> #10Nov 13, 2012 07:13AM

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

ks...@gmail.com <ks...@gmail.com> #11Jan 19, 2013 04:06AM

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10