Errors appear everytime I do a change on scoold-application.conf

[distributev]

Every-time I have the app working fine and then I do a change in scoold-application.conf and I re-start the app I get errors on the screen and on the terminal.

Then I stop the app + empty the /data/* folder + start again and errors are gone and things are working again.

This looks like some configuration values from scoold-application.conf get out of sync with the content of the /data/* folder and errors appear because of that. Emptying the /data/* folder and starting again the app will regenerate /data/* content to be in sync with the new values in scoold-application.conf and everything works well.

This is what is happening? Is this the expected behavior?

What exactly get stored inside the /data/ folder?

[albogdano]

What errors do you see exactly? Just copy/paste the whole console output.
There is nothing to be synced between the configuration file and the database so that makes no sense to me.

[distributev]

Actually without modifying any configuration just having scoold running without any error and simply doing
docker-compose down -v and then docker-compose up -d (I usually do that after I modify configuration this is why I associated the errors with changing configurations)

then I do

rm -rf data/*

and I start again and again it works without errors.

2023-12-02 16:46:41 [DEBUG] Mapped to com.erudika.scoold.controllers.QuestionsController#get(String, HttpServletRequest, Model)
2023-12-02 16:46:41 [ERROR] 403 - 403 - Invalid signature for request GET /v1/question/search/default coming from app scoold
2023-12-02 16:46:41 [DEBUG] Failed to complete request: java.lang.RuntimeException: Failed to execute signed GET request to /v1/question/search/default: 403 - Invalid signature for request GET /v1/question/search/default coming from app scoold
2023-12-02 16:46:41 [WARN ] /community/qa/
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.RuntimeException: Failed to execute signed GET request to /v1/question/search/default: 403 - Invalid signature for request GET /v1/question/search/default coming from app scoold
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
        at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656)
        at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.Server.handle(Server.java:516)
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Failed to execute signed GET request to /v1/question/search/default: 403 - Invalid signature for request GET /v1/question/search/default coming from app scoold
        at com.erudika.para.client.ParaClient.invokeSignedRequest(ParaClient.java:518)
        at com.erudika.para.client.ParaClient.invokeGet(ParaClient.java:408)
        at com.erudika.para.client.ParaClient.find(ParaClient.java:1125)
        at com.erudika.para.client.ParaClient.findQuery(ParaClient.java:937)
        at com.erudika.scoold.controllers.QuestionsController.getQuestions(QuestionsController.java:375)
        at com.erudika.scoold.controllers.QuestionsController.get(QuestionsController.java:88)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Unknown Source)
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1072)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:965)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
        ... 45 common frames omitted

[albogdano]

Is Scoold running as part of a docker-compose command or do you start each container separately, i.e. Para first, then Scoold?
That is not normal and indicates that either the secret key for app:scoold has been changed and is invalid or something worse - perhaps a bug in the auto-initialization code. I will try to reproduce it tomorrow.

[distributev]

docker-compose.yml

version: '3.4'

services:

  scoold:
    image: erudikaltd/scoold:latest_stable
    container_name: scoold
    depends_on:
      - scoold-para
    volumes:
      - /home/infraworker/apps/cvs/shelf-scoold/config/scoold-application.conf:/scoold/application.conf
      - /home/infraworker/apps/cvs/shelf-scoold/config/para-application.conf:/scoold/para-application.conf
    environment:
      - JAVA_OPTS=-Dconfig.file=/scoold/application.conf -Dscoold.autoinit.para_config_file=/scoold/para-application.conf -Dlogging.level.org.springframework=DEBUG
      - BOOT_SLEEP=5
    restart: unless-stopped
    networks:
      - bridge_current_host_cross_containers_net


  scoold-para:
    image: erudikaltd/para:latest_stable
    container_name: scoold-para
    volumes:
      - /home/infraworker/apps/cvs/shelf-scoold/data-para:/para/data
      - /home/infraworker/apps/cvs/shelf-scoold/lib-para:/para/lib
      - /home/infraworker/apps/cvs/shelf-scoold/config/para-application.conf:/para/application.conf
    environment:
      - JAVA_OPTS=-Dconfig.file=/para/application.conf -Dloader.path=/para/lib -Dlogging.level.org.springframework=DEBUG
    restart: unless-stopped
    networks:
      - bridge_current_host_cross_containers_net

networks:
  bridge_current_host_cross_containers_net:
    driver: bridge
    external: true

scoold-application.conf

#############  CORE  #############

scoold.app_name = "Community QA"
scoold.para_access_key = "app:scoold"
scoold.para_secret_key = "8888aSnyCMNkcABGW9+aWjjj8I80gwVAcfc8RTBthEz8d7suTl1111=="
scoold.para_endpoint = "https://para.example.org"
scoold.host_url = "https://www.example.org"
scoold.port = 8000
scoold.env = "production"
scoold.app_secret_key = "oVRiuaHiIcRqNgXH0fYxE09mrrcVwHrWs77nkhmJ5wY="
scoold.admins = "marissa06example.org"
scoold.context_path = "/community/qa"

#############  BASIC AUTHENTICATION  #############

scoold.password_auth_enabled = false

#############  OAUTH 2.0 AUTHENTICATION  #############

scoold.oa2_app_id = "1ptg3wKIsQyoHdsFBIWB9d3c87tiRoZf93vnLhnz"
scoold.oa2_secret = "qtQEiFVsvvZ3aDrB8WrHi4WbEVhw1PuoHTONrvdd"
scoold.security.oauth.authz_url = "https://community.example.org/oauth/authorize"
scoold.security.oauth.token_url = "https://community.example.org/oauth/token"
scoold.security.oauth.profile_url = "https://community.example.org/oauth/me"
scoold.security.oauth.scope = "openid email profile"
scoold.security.oauth.provider = "Login"

#############  CUSTOMIZATION  #############

scoold.footer_links_enabled = false

#############  FRONTEND ASSETS  #############

scoold.inline_css = ".page-footer .row .col.l5.right-align a { display: none; } .page-footer .row .col.l6.sTextCenter { display: none; }"

#############  MISCELLANEOUS  #############

scoold.autoinit.para_config_file = "/scoold/para-application.conf"

para-application.conf

para.root_access_key = "app:para"
para.root_secret_key = "7777qDO58dJG0YZadPWkY6BXdVO8vj5Ts9VEJhVAJ81kHlVa3nU999=="

[albogdano]

Apparently, this was a bug in Para and it's fixed now. You should wait for the new Para release and update your Docker container (make sure you don't use the cached old version of the Para container).
Also, remember that the command docker-compose down will destroy the current working environment of both containers and delete all data in the volumes. Perhaps you should use docker-compose stop instead for stopping Scoold.

[distributev]

docker-compose down does not delete the data in the mapped volumes - I use this command in scoold and in many other apps and the data/databases in the mapped volumes remain in place. Actually, in order to fix the above error, I manually delete the data by executing rm -rf /data/* and then the next docker-compose up -d will start without any error.

[albogdano]

It could be so but on my machine I saw a message "volume removed". Anyway, the command itself is not really an issue, but you will have to upgrade Para to 1.49.1. I'm hoping to release it tomorrow.

[albogdano]

Forgot to mention that you have to update both Scoold and Para to their latest versions for this to work. The new versions are Scoold 1.57.2 and Para 1.49.1 and they are now available

[distributev]

Hello,
Thank you for your work on this project. Was the new code i.e. 1.49.1 already built and published as

    image: erudikaltd/para:latest_stable

?

I say this because this is what I use in the docker-compose.yml and when I stop docker-compose down -v and start again docker-compose up -d I still get the Critical server error. 500 org.springframework.web.util.NestedServletException: Request processing failed; nested exception is on the homepage

I even did docker-compose pull before starting but the error is still coming the same as before.

Maybe I need to do rm -rf data/* one last time and from now one it will work without having to remove the data?

Was the error supposed to go away just by updating to the "latest"?

[albogdano]

Yes, the latest stable tag points to 1.49.1 but you should not expect Docker to automatically update your container image. You should pull the latest image because gou are still using the cached one. Also you must get Scoold 1.57.2 otherwise the error will not go away.

[distributev]

I thought that doing docker-compose up -d --build or docker-compose pull just before docker-compose up -d + having image: erudikaltd/para:latest_stable inside the docker-compose.yml is enough to get the "latest" app.

apparently it is not, unless I missunderstand something about how docker works.

[albogdano]

Scoold will print out its version, so that's one way to check if you're running the latest release.