2019-07-09 22:12:42 +0200 | received badge | ● Famous Question (source) |
2019-07-01 21:12:32 +0200 | received badge | ● Notable Question (source) |
2019-06-27 16:21:59 +0200 | received badge | ● Editor (source) |
2019-06-27 16:17:53 +0200 | answered a question | I have a problem/question regarding the init procedure Hi and thanks for the answer and tests! I'm using the "answer" section simply because the reply doesn't fit a comment. As I saw this question/problem wasn't getting moderated and made public I went ahead and posted it on the github repo for the project as well: https://github.com/telefonicaid/fiwar... My configuration is quite similar. I use a custom build where I simply add a wrapper script to start the main process. This serves as a more convenient way to configure different startup arguments for the main process.
The script: \!/bin/bash /usr/bin/contextBroker -fg -logLevel $ORION_LOG_LEVEL -dbhost $ORION_MONGO_HOST -db $ORION_MONGO_DB \ -dbuser $ORION_MONGO_USER -dbpwd $ORION_MONGO_PASS $ORION_EXTRA_ARGS So my yaml definition for the Pod/DeploymentConfiguration is: command: - /opt/bin/runContextBroker.sh image: "" imagePullPolicy: IfNotPresent env: - name: TZ value: ${ENV_TZ} - name: ORION_LOG_LEVEL valueFrom: configMapKeyRef: name: ${ORION_CONF} key: ORION_LOG_LEVEL - name: ORION_MONGO_HOST valueFrom: configMapKeyRef: name: ${ORION_CONF} key: ORION_MONGO_HOST - name: ORION_MONGO_DB valueFrom: secretKeyRef: key: database-name name: ${MONGODB_ENV} - name: ORION_MONGO_USER valueFrom: configMapKeyRef: name: ${ORION_CONF} key: ORION_MONGO_USER - name: ORION_MONGO_PASS valueFrom: secretKeyRef: key: database-admin-password name: ${MONGODB_ENV} - name: ORION_EXTRA_ARGS valueFrom: configMapKeyRef: name: ${ORION_CONF} key: ORION_EXTRA_ARGS ports: - containerPort: 1026 protocol: TCP The excerpt above uses some parameters that reference a ConfigMap - The problem I have is that sometimes, just like in your test example, the serrvice starts without any problems/right away and sometimes the initialization process gets stuck, the process doesn't begin listening on the 1026 port so it practically doesn't begin to run. What I found is that there's precisely the same step where the init process arrives during failed inits: time=Monday 24 Jun 09:32:17 2019.632Z | lvl=INFO | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=MongoGlobal.cpp[227]:mongoInit | msg=Connected to mongo at mongodb.civ-fiware.svc.cluster.local:admin as user 'admin' If using the INFO log level, this would be the same 42nd line inside the Pod/container log. When the Pod starts without issues, the log gets past this point and shows: time=Monday 24 Jun 09:32:17 2019.632Z | lvl=INFO | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=MongoGlobal.cpp[227]:mongoInit | msg=Connected to ... |
2019-06-27 13:50:03 +0200 | received badge | ● Popular Question (source) |
2019-06-26 08:10:25 +0200 | asked a question | I have a problem/question regarding the init procedure Hello all, I'm trying to deploy the Orion ContextBroker on a Openshift/OKD(Kubernetes) cluster and I'm having a problem with its deployment regarding the initialization time. I'm using the 2.2.0 release tag for the ContextBroker with mongoDB 3.2.0. The startup args for Orion are: -ipv4 -reqPoolSize 100 -notificationMode threadpool:10000:50 -statNotifQueue -statCounters -statSemWait -statTiming -relogAlarms -httpTimeout 100000 The initialization appears to be somewhat inconsistent regarding the time required for the app to become available. The initialization seems to freeze at a certain point which appears in the logs as [1]. The actual service isn't started ( I've tested with different resource allocation and this doesn't seem to be the problem. Also by checking the logs I see some "odd" intervals in the initialization procedure. I have some excerpts at the end of the message, [2], where I can see the last steps of the init procedure being executed(or, at least, logged) at precisely 1 minute intervals. The problem is that once the readiness health check fails, the deployment fails as well. Orion seems to use a lot of RAM which does not get released even if the notification load disappears, from what I saw. The recommendation would be to restart the process, which, in my case, can be automatically handled if I set an upper memory limit for the container. So the initialization process comes again in question...also for the auto-scaling mechanism, etc. Any hints towards how to solve this problem would be much appreciated! Thanks, Dan [1] - last 10-12 lines from ContextBroker's log; DEBUG -t 0-255 time=Wednesday 19 Jun 16:50:35 2019.407Z | lvl=DEBUG | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=connectionOperations.cpp[802]:getWriteConcern | msg=getWriteConcern() |