Initial values

[astoeckl]

I am passing an initial value with a template tag
{%plotly_app initial_arguments='{"artnum": {"value":"111"}}' name="Test" %}
to a inputfield in a dash app
dcc.Input(id='artnum', placeholder='Enter a value...',type='number',value='')

On a local machine it works fine.
After deloyment to a google cloud flexible engine the value is sometimes given to the app. Sometimes the input is blank.
Seems random.

Could i be some chache problem?
Any idea to control this?

[GibbsConsulting]

Given the intermittent behaviour and only when deployed on the google engine, it does sound like some sort of caching issue. The initial template render will store the initial arguments in the default cache from the Django settings file, and they are then retrieved in a subsequent call.

I'm wondering if the actual cache used on google cloud is different, and perhaps not as global in nature as would be needed for this. In the demo app, redis is used as both the messaging structure for the asynchronous functionality and as the cache for Django. Are you in a position to check and/or share the relevant parts of your settings.py file?

If its not this, then there are some other ways in which caching could be causing an issue. However I think this is the best place to look first.

[astoeckl]

In the settings.py there is: # Application definition INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'bootstrap4', 'accounts', 'listnews', 'aktien', 'django_plotly_dash.apps.DjangoPlotlyDashConfig', ] MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'debug_toolbar.middleware.DebugToolbarMiddleware' ] TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [TEMPLATE_DIR], 'APP_DIRS': True, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], }, }, ] WSGI_APPLICATION = 'nstock.wsgi.application' Are there other parts of the file that a relevant?

…

________________________________ Von: Gibbs Consulting <notifications@github.com> Gesendet: Freitag, 9. November 2018 15:40:01 An: GibbsConsulting/django-plotly-dash Cc: Andreas Stöckl; Author Betreff: Re: [GibbsConsulting/django-plotly-dash] Initial values (#71) Given the intermittent behaviour and only when deployed on the google engine, it does sound like some sort of caching issue. The initial template render will store the initial arguments in the default cache from the Django settings file, and they are then retrieved in a subsequent call. I'm wondering if the actual cache used on google cloud is different, and perhaps not as global in nature as would be needed for this. In the demo app, redis is used as both the messaging structure for the asynchronous functionality and as the cache for Django. Are you in a position to check and/or share the relevant parts of your settings.py file? If its not this, then there are some other ways in which caching could be causing an issue. However I think this is the best place to look first. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#71 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXoL6j29hK1hher1cocylTe5tFW-eioDks5utZPBgaJpZM4YVTKi>.

[GibbsConsulting]

Yes - are there any cache-related settings?

For example, the demo in the codebase contains this:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient"
        },
        "KEY_PREFIX": "dpd-demo"
    }
}

# Channels config, to use channel layers

CHANNEL_LAYERS = {
    'default': {
        'BACKEND': 'channels_redis.core.RedisChannelLayer',
        'CONFIG': {
            'hosts': [('127.0.0.1', 6379),],
        },
    },
}

The first of these is used to set up general Django caching and might need adjustment depending on what GCE recommends; any cache will do. The second is only needed if the push functionality is being used.

[astoeckl]

There are not any cache-related settings until now in the settings.

…

________________________________ Von: Gibbs Consulting <notifications@github.com> Gesendet: Freitag, 9. November 2018 18:39:35 An: GibbsConsulting/django-plotly-dash Cc: Andreas Stöckl; Author Betreff: Re: [GibbsConsulting/django-plotly-dash] Initial values (#71) Yes - are there any cache-related settings? For example, the demo in the codebase contains this: CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": { "CLIENT_CLASS": "django_redis.client.DefaultClient" }, "KEY_PREFIX": "dpd-demo" } } # Channels config, to use channel layers CHANNEL_LAYERS = { 'default': { 'BACKEND': 'channels_redis.core.RedisChannelLayer', 'CONFIG': { 'hosts': [('127.0.0.1', 6379),], }, }, } The first of these is used to set up general Django caching and might need adjustment depending on what GCE recommends; any cache will do. The second is only needed if the push functionality is being used. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#71 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXoL6jBtb20ulWZ3Llm2RBv0AHkYcSFMks5utb3XgaJpZM4YVTKi>.

[GibbsConsulting]

In that case, you're using the default cache which is local memory according to the documentation.

So, if there is more than one process serving your app - which seems to be very likely if you're not just running a local debug environment - you won't be sharing information between processes, which would explain the observed issue.

I think the next step is to try using an explicit cache - anything should do as long as its not local to the process.

[astoeckl]

Thank you for the hint. I added: CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11211', } } to the settings. And installled https://pypi.org/project/python-memcached/ memcache is running on on Google cloud AppEngine. Now the initial argument is never given to the dash app

…

________________________________ Von: Gibbs Consulting <notifications@github.com> Gesendet: Freitag, 9. November 2018 18:53:53 An: GibbsConsulting/django-plotly-dash Cc: Andreas Stöckl; Author Betreff: Re: [GibbsConsulting/django-plotly-dash] Initial values (#71) In that case, you're using the default cache which is local memory according to the documentation<https://docs.djangoproject.com/en/2.1/topics/cache/#local-memory-caching>. So, if there is more than one process serving your app - which seems to be very likely if you're not just running a local debug environment - you won't be sharing information between processes, which would explain the observed issue. I think the next step is to try using an explicit cache - anything should do as long as its not local to the process. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#71 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXoL6n2wXUPi2aPoRDygf1UE-lzMNtP_ks5utcExgaJpZM4YVTKi>.

[GibbsConsulting]

Are those memcached settings correct? The IP address is for localhost, rather than a shared cache - perhaps 127.0.0.1 should be replaced by the address of a memcached instance.

For example, this page talks about one of the cache approaches for the flexible environment.

There is a separate need for using something other than the cache, such as the user's session, for storing this information.

[GibbsConsulting]

#91 has now been released. If a cache cannot be used, then setting the cache_arguments flag to False will use a session to propagate the initial arguments to a Dash app.