You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Daniel Watford <da...@foomoo.co.uk> on 2023/03/28 16:09:35 UTC
Help needed to check demo-trunk solr functionality following switch to docker
Hello,
Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site
is now hosted by a docker container running on VM ofbiz-vm1.apache.org.
The changes to the host are captured in PR,
https://github.com/apache/ofbiz-tools/pull/5.
The previous approach to demo-trunk deployment patched the solr plugin to
set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can view
the patch here -
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
.
I believe I have configured the new demo-trunk container to produce the
same solr url, but by using configuration rather than source code changes.
I don't know much about the use of Solr in OFBiz so don't know how to check
that the original demo-trunk behaviour has been maintained.
Please could someone familiar with Solr in OFBiz take a look
https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr
is operating as expected.
Thanks,
Dan.
--
Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 30/03/2023 à 09:55, Jacques Le Roux a écrit :
> We have much enough memory available so you can allocate, say, 3GB to Docker to be safe (or more for the whole, like Postgres or what not).
Ah, I see now you did it already:
@danwatford <https://github.com/danwatford> pushed 1 commit.
* f778e64 <https://github.com/apache/ofbiz-tools/commit/f778e6445d20545783d193b73cf1f20650dc8920> Improved: Increased demo-trunk memory limit to
2400MB (OFBIZ-12786)
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Daniel,
Yep, it's clearly a memory size issue. We have much enough memory available so you can allocate, say, 3GB to Docker to be safe (or more for the whole,
like Postgres or what not).
Sorry, I have no idea why we get a proxy_ajp:error.
I noticed something. The OFBiz demos are supposed to run under the ofbizDemo user.
This was a constraint specified long ago by Infra:
jleroux@ofbiz-vm1:/home/ofbizDemo$ ls
3669011.txt RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT all-manual.sh branch22.01 cronlog-svn-update.log nohup.out stable-manual.sh
trunk.sh
3669011.txt.save all-manual-nicely.sh branch18.12 check-svn-update.sh next-manual.sh port.txt trunk
It's security related. Can't you do the same with Docker or is that constraint unnecessary for Docker with an Infra agreement for the ofbizdocker user
(same security profile), or?
About your question: <<Perhaps other parts of the Java VM are using over 600MB to manage themselves?>>
Are you sure it's only Java related, eg. is Postgres using another process or is it included in the Docker OFBiz component, etc?
HTH
Jacques
Le 29/03/2023 à 21:43, Daniel Watford a écrit :
> Hi Jacques,
>
> The TL;DR is that the ofbiz process ran out of memory and was killed by the
> kernel.
>
> The original limit of 1600MB was being hit, causing an immediate rather
> than graceful kill. This limit has been lifted to 2400MB.
>
> The following shows the steps taken to look into why OFBiz had stopped once
> I had ssh'd to ofbiz-vm1, became root and changed to the
> /home/ofbizdocker/demo-trunk directory
>
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# date
> Wed Mar 29 18:44:16 UTC 2023
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# docker compose ps -a
> NAME IMAGE COMMAND
> SERVICE CREATED STATUS
> PORTS
> demo-trunk-db-1 postgres:13
> "docker-entrypoint.s…" db 16 hours ago Up 16
> hours 5432/tcp
> demo-trunk-ofbiz-1 ghcr.io/apache/ofbiz:trunk-plugins-snapshot
> "/ofbiz/docker-entry…" ofbiz 16 hours ago Exited
> (137) 7 hours ago
>
> The demo-trunk-ofbiz-1 container stopped 7 hours ago, but not much
> information to go on here.
>
> Reviewing the logs with `docker compose logs` does not reveal anything
> about why the demo-trunk-ofbiz-1 container shut down.
>
>
> Next we'll try inspecting the stopped container:
>
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# docker inspect
> demo-trunk-ofbiz-1
> [{
> "Id":
> "8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092",
> "Created": "2023-03-29T02:35:03.522931049Z",
> "Path": "/ofbiz/docker-entrypoint.sh",
> "Args": [
> "bin/ofbiz"
> ],
> "State": {
> "Status": "exited",
> "Running": false,
> "Paused": false,
> "Restarting": false,
> "OOMKilled": true,
> "Dead": false,
> "Pid": 0,
> "ExitCode": 137,
> "Error": "",
> "StartedAt": "2023-03-29T02:35:04.063103982Z",
> "FinishedAt": "2023-03-29T11:18:12.827856157Z"
>
> [... snip ...]
>
> From the above we see the container was OOMKilled (out of memory)
>
> It is likely that the OFBiz deployment attempted to exceed its 1600MB limit
> defined in the docker-compose.yml file.
>
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# cat docker-compose.yml
> version: "2.4"
>
> services:
> db:
> image: postgres:13
> mem_limit: 300M
> memswap_limit: 300M
> cpu_shares: 200
> restart: "no"
> volumes:
> - ./postgres-initdb.d:/docker-entrypoint-initdb.d
> env_file:
> - postgres.env
> - ofbiz-postgres.env
>
> ofbiz:
> image: ghcr.io/apache/ofbiz:trunk-plugins-snapshot
> mem_limit: 1600M
> memswap_limit: 1600M
> cpu_shares: 200
> ports:
> - 127.0.0.1:8009:8009
> volumes:
> -
> ./after-config-applied.d:/docker-entrypoint-hooks/after-config-applied.d
> env_file:
> - ofbiz-postgres.env
> environment:
> OFBIZ_HOST: demo-trunk.ofbiz.apache.org
> OFBIZ_ENABLE_AJP_PORT: 1
> OFBIZ_DATA_LOAD: demo
> OFBIZ_CONTENT_URL_PREFIX: https://demo-trunk.ofbiz.apache.org
>
> Now that we know ofbiz will killed due to running out of memory at 11:18:12
> UTC, we can check the logs again to see what requests were being made
> around this time.
>
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk#
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,237 |-0.0.0.0-8009-exec-1
> |ControlServlet |T| [[[ordermgr::ajaxSetUserPreference
> (Domain:https://demo-trunk.ofbiz.apache.org)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,241 |-0.0.0.0-8009-exec-1
> |ServiceDispatcher |T| Sync service
> [order/preferenceGetSetPermission] finished in [1] milliseconds
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
> |ServiceDispatcher |T| Sync service [order/setUserPreference]
> finished in [3] milliseconds
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
> |RequestHandler |I| Ran Event [service:#setUserPreference]
> from [request], result is [success]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
> |ServerHitBin |I| Visit delegatorName=default,
> ServerHitBin delegatorName=default
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,246 |-0.0.0.0-8009-exec-1
> |ControlServlet |T| [[[ordermgr::ajaxSetUserPreference
> (Domain:https://demo-trunk.ofbiz.apache.org)] Request Done-
> total:0.009,since last([ordermgr::ajaxSe...):0.009]]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,294 |-0.0.0.0-8009-exec-8
> |ControlServlet |T| [[[ordermgr::createOrderConversation
> (Domain:https://demo-trunk.ofbiz.apache.org)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,314 |-0.0.0.0-8009-exec-8
> |ConfigXMLReader |I| controller loaded: 0.0s, 0 requests, 0
> views in
> file:/ofbiz/framework/common/webcommon/WEB-INF/handlers-controller.xml
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,315 |-0.0.0.0-8009-exec-8
> |ConfigXMLReader |I| controller loaded: 0.006s, 52 requests,
> 21 views in
> file:/ofbiz/framework/common/webcommon/WEB-INF/common-controller.xml
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,320 |-0.0.0.0-8009-exec-8
> |ConfigXMLReader |I| controller loaded: 0.0s, 4 requests, 0
> views in file:/ofbiz/applications/commonext/webapp/WEB-INF/controller.xml
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,376 |-0.0.0.0-8009-exec-8
> |ConfigXMLReader |I| controller loaded: 0.004s, 347 requests,
> 134 views in
> file:/ofbiz/applications/content/webapp/content/WEB-INF/controller.xml
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,380 |-0.0.0.0-8009-exec-8
> |ConfigXMLReader |I| controller loaded: 0.077s, 380 requests,
> 153 views in
> file:/ofbiz/applications/order/webapp/ordermgr/WEB-INF/controller.xml
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,384 |-0.0.0.0-8009-exec-8
> |ServiceDispatcher |E| Incoming context (in runSync :
> createOrderConversation) does not match expected requirements
> demo-trunk-ofbiz-1 | org.apache.ofbiz.service.ServiceValidationException:
> The following required parameter is missing: communicationEventPrpTypId
> demo-trunk-ofbiz-1 | at
> org.apache.ofbiz.service.ModelService.resolveRequiredValues(ModelService.java:1270)
> ~[ofbiz.jar:?]
> demo-trunk-ofbiz-1 | at
> org.apache.ofbiz.service.ModelService.validate(ModelService.java:1150)
> ~[ofbiz.jar:?]
> .
> .
> .
> demo-trunk-ofbiz-1 | at
> org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433)
> ~[tomcat-coyote-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
> ~[tomcat-coyote-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:926)
> ~[tomcat-coyote-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1791)
> ~[tomcat-coyote-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> ~[tomcat-coyote-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
> ~[tomcat-util-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
> ~[tomcat-util-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> ~[tomcat-util-9.0.72.jar:9.0.72]
> demo-trunk-ofbiz-1 | at java.lang.Thread.run(Thread.java:833) ~[?:?]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
> |ServiceDispatcher |T| [[Sync service failed...-
> total:0.0,since last(Begin):0.0]] - 'order / createOrderConversation'
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
> |TransactionUtil |I| Transaction rolled back
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
> |TransactionUtil |W| Not committing transaction, status is No
> Transaction (6)
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
> |RequestHandler |I| Ran Event
> [service:#createOrderConversation] from [request], result is [error]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
> |RequestHandler |E| Request createOrderConversation caused
> an error with the following message: [The following required parameter is
> missing: communicationEventPrpTypId]
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,386 |-0.0.0.0-8009-exec-8
> |RequestHandler |I| Sending redirect to: [
> https://demo-trunk.ofbiz.apache.org:443/ordermgr/control/orderview?orderId=WSCO10012].
> Hidden sessionId by default.
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,395 |-0.0.0.0-8009-exec-8
> |ServerHitBin |I| Visit delegatorName=default,
> ServerHitBin delegatorName=default
> demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,397 |-0.0.0.0-8009-exec-8
> |ControlServlet |T| [[[ordermgr::createOrderConversation
> (Domain:https://demo-trunk.ofbiz.apache.org)] Request Done-
> total:0.103,since last([ordermgr::create...):0.103]]
>
> So it looks like a request was made to createOrderConversation which failed
> and issued a redirect to
> https://demo-trunk.ofbiz.apache.org:443/ordermgr/control/orderview?orderId=WSCO10012.
> And then the logs show nothing else.
>
>
>
> Next we can take a look at /var/log/kern.log around 11:18:12 UTC to see if
> we can find out why the ofbiz service was killed.
>
> root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# cd /var/log
> root@ofbiz-vm1:/var/log# less kern.log
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039472] C2 CompilerThre invoked
> oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039481] CPU: 0 PID: 3444767
> Comm: C2 CompilerThre Not tainted 5.15.0-1028-aws #32~20.04.1-Ubuntu
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039484] Hardware name: Xen HVM
> domU, BIOS 4.11.amazon 08/24/2006
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039486] Call Trace:
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039489] <TASK>
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039492] dump_stack_lvl+0x4a/0x63
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039498] dump_stack+0x10/0x16
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039501] dump_header+0x53/0x225
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039505]
> oom_kill_process.cold+0xb/0x10
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039509]
> out_of_memory+0x1dc/0x530
> .
> .
> .
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039576] memory: usage 1638400kB,
> limit 1638400kB, failcnt 0
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039578] memory+swap: usage
> 1638400kB, limit 1638400kB, failcnt 1441
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039579] kmem: usage 8120kB,
> limit 9007199254740988kB, failcnt 0
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039581] Memory cgroup stats for
> /docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092:
> .
> .
> .
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039598] Tasks state (memory
> values in pages):
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039599] [ pid ] uid tgid
> total_vm rss pgtables_bytes swapents oom_score_adj name
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039604] [3442255] 1000 3442255
> 1744968 417268 4272128 0 0 java
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039607]
> oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,mems_allowed=0,oom_memcg=/docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,task_memcg=/docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,task=java,pid=3442255,uid=1000
> Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039805] Memory cgroup out of
> memory: Killed process 3442255 (java) total-vm:6979872kB,
> anon-rss:1624552kB, file-rss:44520kB, shmem-rss:0kB, UID:1000
> pgtables:4172kB oom_score_adj:0
>
>
> From the above logs we have line,
> "Memory cgroup out of memory: Killed process 3442255 (java)
> total-vm:6979872kB, anon-rss:1624552kB, file-rss:44520kB, shmem-rss:0kB,
> UID:1000 pgtables:4172kB oom_score_adj:0"
>
> This tells us that process 3442255, a java process was killed.
>
> Further up in the log we have line:
> "memory: usage 1638400kB, limit 1638400kB, failcnt 0"
> Basically our ofbiz java process was using 1600MB, hitting its memory
> limit. This is surprising though as our ofbiz processes launch with
> parameters: -Xms128M -Xmx1024M
> These parameters should limit heap usage to 1024MB. Perhaps other parts of
> the Java VM are using over 600MB to manage themselves?
>
> As a work around I will increase the limit assigned to the docker ofbiz
> container, but it would be good to be able to predict expected memory usage
> by OFBiz.
>
>
>
> Once OFBiz was up and running again, there were still problems connecting
> to https://demo-trunk.ofbiz.apache.org/partymgr.
>
> [Wed Mar 29 19:27:01.264143 2023] [proxy_ajp:error] [pid 3849696:tid
> 139767516272384] (120006)APR does not understand this error code: [client
> 185.191.171.12:2680] AH00878: read response failed from 127.0.0.1:8009
> (localhost)
>
> It seems that Apache HTTPd did not like the responses it was getting from
> OFBiz Tomcat on port 8009.
>
> I didn't know how to investigate this issue any further, so ended up
> removing and recreating both the database and ofbiz containers. Once this
> was done demo-trunk appears to be working normally.
>
>
> Any suggestions on how to investigate the issue with the AJP port if
> similar problems occur will be gratefully received.
>
>
>
> Thanks,
>
> Dan.
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Jacques,
The TL;DR is that the ofbiz process ran out of memory and was killed by the
kernel.
The original limit of 1600MB was being hit, causing an immediate rather
than graceful kill. This limit has been lifted to 2400MB.
The following shows the steps taken to look into why OFBiz had stopped once
I had ssh'd to ofbiz-vm1, became root and changed to the
/home/ofbizdocker/demo-trunk directory
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# date
Wed Mar 29 18:44:16 UTC 2023
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# docker compose ps -a
NAME IMAGE COMMAND
SERVICE CREATED STATUS
PORTS
demo-trunk-db-1 postgres:13
"docker-entrypoint.s…" db 16 hours ago Up 16
hours 5432/tcp
demo-trunk-ofbiz-1 ghcr.io/apache/ofbiz:trunk-plugins-snapshot
"/ofbiz/docker-entry…" ofbiz 16 hours ago Exited
(137) 7 hours ago
The demo-trunk-ofbiz-1 container stopped 7 hours ago, but not much
information to go on here.
Reviewing the logs with `docker compose logs` does not reveal anything
about why the demo-trunk-ofbiz-1 container shut down.
Next we'll try inspecting the stopped container:
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# docker inspect
demo-trunk-ofbiz-1
[{
"Id":
"8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092",
"Created": "2023-03-29T02:35:03.522931049Z",
"Path": "/ofbiz/docker-entrypoint.sh",
"Args": [
"bin/ofbiz"
],
"State": {
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": true,
"Dead": false,
"Pid": 0,
"ExitCode": 137,
"Error": "",
"StartedAt": "2023-03-29T02:35:04.063103982Z",
"FinishedAt": "2023-03-29T11:18:12.827856157Z"
[... snip ...]
From the above we see the container was OOMKilled (out of memory)
It is likely that the OFBiz deployment attempted to exceed its 1600MB limit
defined in the docker-compose.yml file.
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# cat docker-compose.yml
version: "2.4"
services:
db:
image: postgres:13
mem_limit: 300M
memswap_limit: 300M
cpu_shares: 200
restart: "no"
volumes:
- ./postgres-initdb.d:/docker-entrypoint-initdb.d
env_file:
- postgres.env
- ofbiz-postgres.env
ofbiz:
image: ghcr.io/apache/ofbiz:trunk-plugins-snapshot
mem_limit: 1600M
memswap_limit: 1600M
cpu_shares: 200
ports:
- 127.0.0.1:8009:8009
volumes:
-
./after-config-applied.d:/docker-entrypoint-hooks/after-config-applied.d
env_file:
- ofbiz-postgres.env
environment:
OFBIZ_HOST: demo-trunk.ofbiz.apache.org
OFBIZ_ENABLE_AJP_PORT: 1
OFBIZ_DATA_LOAD: demo
OFBIZ_CONTENT_URL_PREFIX: https://demo-trunk.ofbiz.apache.org
Now that we know ofbiz will killed due to running out of memory at 11:18:12
UTC, we can check the logs again to see what requests were being made
around this time.
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# docker compose logs | tail -70
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,237 |-0.0.0.0-8009-exec-1
|ControlServlet |T| [[[ordermgr::ajaxSetUserPreference
(Domain:https://demo-trunk.ofbiz.apache.org)] Request Begun,
encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,241 |-0.0.0.0-8009-exec-1
|ServiceDispatcher |T| Sync service
[order/preferenceGetSetPermission] finished in [1] milliseconds
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
|ServiceDispatcher |T| Sync service [order/setUserPreference]
finished in [3] milliseconds
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
|RequestHandler |I| Ran Event [service:#setUserPreference]
from [request], result is [success]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,244 |-0.0.0.0-8009-exec-1
|ServerHitBin |I| Visit delegatorName=default,
ServerHitBin delegatorName=default
demo-trunk-ofbiz-1 | 2023-03-29 11:18:05,246 |-0.0.0.0-8009-exec-1
|ControlServlet |T| [[[ordermgr::ajaxSetUserPreference
(Domain:https://demo-trunk.ofbiz.apache.org)] Request Done-
total:0.009,since last([ordermgr::ajaxSe...):0.009]]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,294 |-0.0.0.0-8009-exec-8
|ControlServlet |T| [[[ordermgr::createOrderConversation
(Domain:https://demo-trunk.ofbiz.apache.org)] Request Begun,
encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,314 |-0.0.0.0-8009-exec-8
|ConfigXMLReader |I| controller loaded: 0.0s, 0 requests, 0
views in
file:/ofbiz/framework/common/webcommon/WEB-INF/handlers-controller.xml
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,315 |-0.0.0.0-8009-exec-8
|ConfigXMLReader |I| controller loaded: 0.006s, 52 requests,
21 views in
file:/ofbiz/framework/common/webcommon/WEB-INF/common-controller.xml
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,320 |-0.0.0.0-8009-exec-8
|ConfigXMLReader |I| controller loaded: 0.0s, 4 requests, 0
views in file:/ofbiz/applications/commonext/webapp/WEB-INF/controller.xml
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,376 |-0.0.0.0-8009-exec-8
|ConfigXMLReader |I| controller loaded: 0.004s, 347 requests,
134 views in
file:/ofbiz/applications/content/webapp/content/WEB-INF/controller.xml
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,380 |-0.0.0.0-8009-exec-8
|ConfigXMLReader |I| controller loaded: 0.077s, 380 requests,
153 views in
file:/ofbiz/applications/order/webapp/ordermgr/WEB-INF/controller.xml
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,384 |-0.0.0.0-8009-exec-8
|ServiceDispatcher |E| Incoming context (in runSync :
createOrderConversation) does not match expected requirements
demo-trunk-ofbiz-1 | org.apache.ofbiz.service.ServiceValidationException:
The following required parameter is missing: communicationEventPrpTypId
demo-trunk-ofbiz-1 | at
org.apache.ofbiz.service.ModelService.resolveRequiredValues(ModelService.java:1270)
~[ofbiz.jar:?]
demo-trunk-ofbiz-1 | at
org.apache.ofbiz.service.ModelService.validate(ModelService.java:1150)
~[ofbiz.jar:?]
.
.
.
demo-trunk-ofbiz-1 | at
org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433)
~[tomcat-coyote-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
~[tomcat-coyote-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:926)
~[tomcat-coyote-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1791)
~[tomcat-coyote-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
~[tomcat-coyote-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
~[tomcat-util-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
~[tomcat-util-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
~[tomcat-util-9.0.72.jar:9.0.72]
demo-trunk-ofbiz-1 | at java.lang.Thread.run(Thread.java:833) ~[?:?]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
|ServiceDispatcher |T| [[Sync service failed...-
total:0.0,since last(Begin):0.0]] - 'order / createOrderConversation'
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
|TransactionUtil |I| Transaction rolled back
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
|TransactionUtil |W| Not committing transaction, status is No
Transaction (6)
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
|RequestHandler |I| Ran Event
[service:#createOrderConversation] from [request], result is [error]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,385 |-0.0.0.0-8009-exec-8
|RequestHandler |E| Request createOrderConversation caused
an error with the following message: [The following required parameter is
missing: communicationEventPrpTypId]
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,386 |-0.0.0.0-8009-exec-8
|RequestHandler |I| Sending redirect to: [
https://demo-trunk.ofbiz.apache.org:443/ordermgr/control/orderview?orderId=WSCO10012].
Hidden sessionId by default.
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,395 |-0.0.0.0-8009-exec-8
|ServerHitBin |I| Visit delegatorName=default,
ServerHitBin delegatorName=default
demo-trunk-ofbiz-1 | 2023-03-29 11:18:12,397 |-0.0.0.0-8009-exec-8
|ControlServlet |T| [[[ordermgr::createOrderConversation
(Domain:https://demo-trunk.ofbiz.apache.org)] Request Done-
total:0.103,since last([ordermgr::create...):0.103]]
So it looks like a request was made to createOrderConversation which failed
and issued a redirect to
https://demo-trunk.ofbiz.apache.org:443/ordermgr/control/orderview?orderId=WSCO10012.
And then the logs show nothing else.
Next we can take a look at /var/log/kern.log around 11:18:12 UTC to see if
we can find out why the ofbiz service was killed.
root@ofbiz-vm1:/home/ofbizdocker/demo-trunk# cd /var/log
root@ofbiz-vm1:/var/log# less kern.log
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039472] C2 CompilerThre invoked
oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039481] CPU: 0 PID: 3444767
Comm: C2 CompilerThre Not tainted 5.15.0-1028-aws #32~20.04.1-Ubuntu
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039484] Hardware name: Xen HVM
domU, BIOS 4.11.amazon 08/24/2006
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039486] Call Trace:
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039489] <TASK>
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039492] dump_stack_lvl+0x4a/0x63
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039498] dump_stack+0x10/0x16
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039501] dump_header+0x53/0x225
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039505]
oom_kill_process.cold+0xb/0x10
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039509]
out_of_memory+0x1dc/0x530
.
.
.
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039576] memory: usage 1638400kB,
limit 1638400kB, failcnt 0
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039578] memory+swap: usage
1638400kB, limit 1638400kB, failcnt 1441
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039579] kmem: usage 8120kB,
limit 9007199254740988kB, failcnt 0
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039581] Memory cgroup stats for
/docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092:
.
.
.
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039598] Tasks state (memory
values in pages):
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039599] [ pid ] uid tgid
total_vm rss pgtables_bytes swapents oom_score_adj name
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039604] [3442255] 1000 3442255
1744968 417268 4272128 0 0 java
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039607]
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,mems_allowed=0,oom_memcg=/docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,task_memcg=/docker/8afc7a9b0a1f34c7a72f4b24f4bb9f2679233821f1a9697302719ac0a144b092,task=java,pid=3442255,uid=1000
Mar 29 11:18:12 ofbiz-vm1 kernel: [3983121.039805] Memory cgroup out of
memory: Killed process 3442255 (java) total-vm:6979872kB,
anon-rss:1624552kB, file-rss:44520kB, shmem-rss:0kB, UID:1000
pgtables:4172kB oom_score_adj:0
From the above logs we have line,
"Memory cgroup out of memory: Killed process 3442255 (java)
total-vm:6979872kB, anon-rss:1624552kB, file-rss:44520kB, shmem-rss:0kB,
UID:1000 pgtables:4172kB oom_score_adj:0"
This tells us that process 3442255, a java process was killed.
Further up in the log we have line:
"memory: usage 1638400kB, limit 1638400kB, failcnt 0"
Basically our ofbiz java process was using 1600MB, hitting its memory
limit. This is surprising though as our ofbiz processes launch with
parameters: -Xms128M -Xmx1024M
These parameters should limit heap usage to 1024MB. Perhaps other parts of
the Java VM are using over 600MB to manage themselves?
As a work around I will increase the limit assigned to the docker ofbiz
container, but it would be good to be able to predict expected memory usage
by OFBiz.
Once OFBiz was up and running again, there were still problems connecting
to https://demo-trunk.ofbiz.apache.org/partymgr.
[Wed Mar 29 19:27:01.264143 2023] [proxy_ajp:error] [pid 3849696:tid
139767516272384] (120006)APR does not understand this error code: [client
185.191.171.12:2680] AH00878: read response failed from 127.0.0.1:8009
(localhost)
It seems that Apache HTTPd did not like the responses it was getting from
OFBiz Tomcat on port 8009.
I didn't know how to investigate this issue any further, so ended up
removing and recreating both the database and ofbiz containers. Once this
was done demo-trunk appears to be working normally.
Any suggestions on how to investigate the issue with the AJP port if
similar problems occur will be gratefully received.
Thanks,
Dan.
On Wed, 29 Mar 2023 at 19:21, Jacques Le Roux <ja...@les7arts.com>
wrote:
> Hi Daniel,
>
> The trunk demo is down since early afternoon, normal ?
>
> Received connection from - /127.0.0.1 : 43768
> 2023-03-28 15:41:39,866 |OFBiz-AdminServer |ContainerLoader
> |I| Shutting down containers
> 2023-03-28 15:41:39,867 |OFBiz-AdminServer |ContainerLoader
> |I| Stopping container catalina-container
> [...]
> Mar 28, 2023 3:41:40 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-nio-127.0.0.1-8009"]
> Mar 28, 2023 3:41:40 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-nio-8080"]
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ContainerLoader
> |I| Stopped container catalina-container
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ContainerLoader
> |I| Stopping container service-container
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |JobPoller
> |I| Shutting down JobPoller.
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |JobPoller
> |I| JobPoller shutdown completed.
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer
> |I| Removing from cache dispatcher: default
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher
> |I| De-Registering dispatcher: default
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer
> |I| Removing from cache dispatcher: rest-api
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher
> |I| De-Registering dispatcher: rest-api
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer
> |I| Removing from cache dispatcher: entity-default
> 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher
> |I| De-Registering dispatcher: entity-default
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ServiceDispatcher
> |I| Shutting down the service engine...
> 2023-03-28 15:41:40,139 |OFBiz-JobPoller |JobPoller
> |I| JobPoller thread stopped.
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopped container service-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopping container delegator-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopped container delegator-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopping container admin-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopped container admin-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopping container component-container
> 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader
> |I| Stopped container component-container
>
> Sorry, I have no time yet to check further.
>
> Jacques
>
> Le 28/03/2023 à 18:09, Daniel Watford a écrit :
> > Hello,
> >
> > Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk
> site
> > is now hosted by a docker container running on VM ofbiz-vm1.apache.org.
> >
> > The changes to the host are captured in PR,
> > https://github.com/apache/ofbiz-tools/pull/5.
> >
> > The previous approach to demo-trunk deployment patched the solr plugin to
> > set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can
> view
> > the patch here -
> >
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
> > .
> >
> > I believe I have configured the new demo-trunk container to produce the
> > same solr url, but by using configuration rather than source code
> changes.
> >
> > I don't know much about the use of Solr in OFBiz so don't know how to
> check
> > that the original demo-trunk behaviour has been maintained.
> >
> > Please could someone familiar with Solr in OFBiz take a look
> > https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if
> Solr
> > is operating as expected.
> >
> > Thanks,
> >
> > Dan.
> >
>
--
Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Daniel,
The trunk demo is down since early afternoon, normal ?
Received connection from - /127.0.0.1 : 43768
2023-03-28 15:41:39,866 |OFBiz-AdminServer |ContainerLoader |I| Shutting down containers
2023-03-28 15:41:39,867 |OFBiz-AdminServer |ContainerLoader |I| Stopping container catalina-container
[...]
Mar 28, 2023 3:41:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["ajp-nio-127.0.0.1-8009"]
Mar 28, 2023 3:41:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-nio-8080"]
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ContainerLoader |I| Stopped container catalina-container
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ContainerLoader |I| Stopping container service-container
2023-03-28 15:41:40,138 |OFBiz-AdminServer |JobPoller |I| Shutting down JobPoller.
2023-03-28 15:41:40,138 |OFBiz-AdminServer |JobPoller |I| JobPoller shutdown completed.
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer |I| Removing from cache dispatcher: default
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher |I| De-Registering dispatcher: default
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer |I| Removing from cache dispatcher: rest-api
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher |I| De-Registering dispatcher: rest-api
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer |I| Removing from cache dispatcher: entity-default
2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher |I| De-Registering dispatcher: entity-default
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ServiceDispatcher |I| Shutting down the service engine...
2023-03-28 15:41:40,139 |OFBiz-JobPoller |JobPoller |I| JobPoller thread stopped.
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopped container service-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopping container delegator-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopped container delegator-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopping container admin-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopped container admin-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopping container component-container
2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader |I| Stopped container component-container
Sorry, I have no time yet to check further.
Jacques
Le 28/03/2023 à 18:09, Daniel Watford a écrit :
> Hello,
>
> Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site
> is now hosted by a docker container running on VM ofbiz-vm1.apache.org.
>
> The changes to the host are captured in PR,
> https://github.com/apache/ofbiz-tools/pull/5.
>
> The previous approach to demo-trunk deployment patched the solr plugin to
> set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can view
> the patch here -
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
> .
>
> I believe I have configured the new demo-trunk container to produce the
> same solr url, but by using configuration rather than source code changes.
>
> I don't know much about the use of Solr in OFBiz so don't know how to check
> that the original demo-trunk behaviour has been maintained.
>
> Please could someone familiar with Solr in OFBiz take a look
> https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr
> is operating as expected.
>
> Thanks,
>
> Dan.
>
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for the clarification Daniel, much appreciated
Le 29/03/2023 à 11:52, Daniel Watford a écrit :
> Hi Jacques,
>
> On the page, https://github.com/apache/ofbiz-framework, at the right-hand
> side, under Releases and above Contributors, you will see the Packages
> section. This lists the packages associated with the ofbiz-framework github
> repository.
>
> Clicking on the OFBiz package above will take you to
> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz.
>
>
> Container systems, such as Docker and Podman, pull container images from
> registries.
>
> Examples of some well known registries are:
> - registry-1.docker.io (Docker Hub)
> - ghcr.io (GitHub Container Registry)
> - mcr.microsoft.com (Microsoft Container Registry)
>
> Organisations can also operate their own private container registries.
>
> Within a container registry, we find repositories. Some examples:
> - ghcr.io/apache/ofbiz (OFBiz container repository)
> - mcr.microsoft.com/azure-cli (Azure command line interface)
> - hub.docker.com/_/httpd/ (Apache HTTPd)
>
> Repositories store multiple versions of container images, some of which are
> tagged. We can see all container images in the ofbiz repository at these
> links:
> -
> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=tagged
> -
> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=untagged
>
> The tags help users find a particular version of a container image. Tags
> can be 'moved' to different container image versions as newer versions are
> published. A common tag, although not used in the images published for
> OFBiz, is the 'latest' tag.
>
> Note: Although the above discusses 'container images', really we are just
> talking about files arranged in a well known manner and/or accessible
> behind the well known REST APIs of the registries. Container registries are
> often implemented using artifact management systems, such as Artifactory
> and Nexus. We can think of a container registry as analogous to a Maven
> repository in that artifacts are laid out in a common format.
>
> GitHub Packages is a product offering from GitHub to provide storage and
> publication of various artifacts (packages). The GitHub Container Registry
> is a component of that product offering.
>
> When choosing a place to publish OFBiz container images to, I considered
> Docker Hub, the Apache Foundation's Artifactory instance and GitHub
> Packages.
>
> There was sufficient friction to getting up and running publishing to
> Docker Hub. I would have needed assistance from INFRA, and documentation
> wasn't clear on precisely what information/support I would have needed to
> request.
>
> Plus, the recent policy changes from Docker Inc meant I didn't want to
> expend too much effort there.
>
> GitHub packages seemed a nice low-friction direction to go in as it
> integrated well with GitHub Actions. It also appeared to be growing in
> recognition as a location to publish container image.
>
> During the GitHub Actions build of the OFBiz container images (see
> .github/workflows/docker-image.yml), we use the docker/login-action to log
> in to ghcr.io (GitHub Packages Container Registry). The login makes use of
> the GITHUB_TOKEN secret which is included by default in the workflow. No
> additional configuration or permissions were required to access the
> registry.
>
> Later in the workflow, we use the docker/build-push-action to create the
> docker image and push to ghcr.io.
>
> We do not publish the OFBiz container images to DockerHub. However we do
> build our container images based on the eclipse-temurin:17 image.
>
> Since the image 'eclipse-temurin:17' identifier does not include a
> hostname, the default hostname of registry-1.docker.io (i.e. Docker Hub) is
> used. We do therefore depend on an image from Docker Hub, although we could
> explore whether eclipse-temurin is available from any other public
> container registries and use that instead.
>
> Hope that helps,
>
> Dan.
>
> On Wed, 29 Mar 2023 at 10:01, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> Daniel,
>>
>> I have another minor question: how works and special is
>> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz ? I can't
>> see it locally nor
>> from https://github.com/apache/ofbiz-framework
>> I guess it's not related to Docker Hub, right ?
>>
>> TIA
>>
>> Le 29/03/2023 à 09:33, Daniel Watford a écrit :
>>> Hi Jacques,
>>>
>>> Answers to your questions below.
>>>
>>> 1 - Yes, we should wait to be sure that nothing has been broken by the
>> move to a container deployment to trunk. If/when we are happy then we can
>>> merge ofbiz-tools PR5 into master, bringing in and squashing the commits
>> currently in the docker-experimental branch.
>>> If we discover an issue with docker-trunk we can revert. I decided to
>> use a PR to capture the changes to make it a bit easier for folks without
>>> access to ofbiz-vm1 to review.
>>>
>>> I have seen some errors in the logs related to lack of database
>> connections, probably due to my use of a Postgres database for the
>> demo-trunk
>>> deployment. As I write this I realise that by using a postgres rather
>> than the embedded Derby I have already failed in delivering a like-for-like
>>> version of demo-trunk. If wanted by the dev community, I can switch
>> demo-trunk to use Derby, but I think it is valuable to have an external
>> database
>>> deployment publicly visible.
>>>
>>> I will look into the errors in the logs soon.
>>>
>>>
>>> 2 - I don't have a problem with using AsciiDoc instead of Markdown, I
>> just haven't dealt with it myself yet.
>>> Perhaps someone else could convert that file for us. :)
>>>
>>> I agree that the content in DOCKER.md is not intended to form part of
>> the official OFBiz documentation, but I imagine in the future we might want
>> to
>>> point potential users towards the container images as an unsupported
>> convenience. In that case we would probably need to rework DOCKER.[md|adoc]
>> to
>>> give appropriate deployment guidance, perhaps with separate documents to
>> explain the container build process.
>>>
>>> 3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather
>> than danwatford/ofbiz-framework was an oversight on my part. I'll get it
>>> cleaned up.
>>>
>>> Thanks,
>>>
>>> Dan.
>>>
>>> On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>> Hi Daniel,
>>>
>>> First, thanks for all your work!
>>>
>>> I had a quick look and Solr demo is working as expected. We are not
>> up to date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.
>>> Now, I have few questions/notes for you and the community. You
>> mentioned in a previous email:
>>> Le 22/03/2023 à 17:49, Daniel Watford a écrit :
>>>> If consensus is established, then changes shall be initially made
>> in a way
>>>> allowing them to be quickly reversed if needed. Once the demo-trunk
>> site is
>>>> observed as running correctly, and with refreshes applied daily,
>> then more
>>>> permanent changes can be applied to the demo VM and changes
>> committed to
>>>> https://github.com/apache/ofbiz-tools/tree/master/demo-backup
>> accordingly.
>>> 1. I guess we should now wait for at least another day before
>> merging the docker-experimental branch into ofbiz-tools, right?
>>> 2. We switched from using Markdown to AsciiDoc. I just want to say
>> that you created
>>> https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md.
>> I don't think it's an issue because we don't want to expose that in the
>>> site, it's rather for Docker users, right?
>>> 3. (unrelated to docker effort) I guess we should remove the
>> https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, right?
>> (there
>>> are more docker unrelated branches to clean, I'll send another
>> email for that)
>>> Again, thanks!
>>>
>>> Jacques
>>>
>>> Le 28/03/2023 à 18:09, Daniel Watford a écrit :
>>>> Hello,
>>>>
>>>> Perhttps://issues.apache.org/jira/browse/OFBIZ-12786, the
>> demo-trunk site
>>>> is now hosted by a docker container running on
>> VMofbiz-vm1.apache.org <http://ofbiz-vm1.apache.org>.
>>>> The changes to the host are captured in PR,
>>>> https://github.com/apache/ofbiz-tools/pull/5.
>>>>
>>>> The previous approach to demo-trunk deployment patched the solr
>> plugin to
>>>> set the solr URL tohttps://demo-trunk.ofbiz.apache.org/solr. You
>> can view
>>>> the patch here -
>>>>
>> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
>>>> .
>>>>
>>>> I believe I have configured the new demo-trunk container to produce
>> the
>>>> same solr url, but by using configuration rather than source code
>> changes.
>>>> I don't know much about the use of Solr in OFBiz so don't know how
>> to check
>>>> that the original demo-trunk behaviour has been maintained.
>>>>
>>>> Please could someone familiar with Solr in OFBiz take a look
>>>> https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see
>> if Solr
>>>> is operating as expected.
>>>>
>>>> Thanks,
>>>>
>>>> Dan.
>>>>
>>>
>>> --
>>> Daniel Watford
>
>
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Jacques,
On the page, https://github.com/apache/ofbiz-framework, at the right-hand
side, under Releases and above Contributors, you will see the Packages
section. This lists the packages associated with the ofbiz-framework github
repository.
Clicking on the OFBiz package above will take you to
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz.
Container systems, such as Docker and Podman, pull container images from
registries.
Examples of some well known registries are:
- registry-1.docker.io (Docker Hub)
- ghcr.io (GitHub Container Registry)
- mcr.microsoft.com (Microsoft Container Registry)
Organisations can also operate their own private container registries.
Within a container registry, we find repositories. Some examples:
- ghcr.io/apache/ofbiz (OFBiz container repository)
- mcr.microsoft.com/azure-cli (Azure command line interface)
- hub.docker.com/_/httpd/ (Apache HTTPd)
Repositories store multiple versions of container images, some of which are
tagged. We can see all container images in the ofbiz repository at these
links:
-
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=tagged
-
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=untagged
The tags help users find a particular version of a container image. Tags
can be 'moved' to different container image versions as newer versions are
published. A common tag, although not used in the images published for
OFBiz, is the 'latest' tag.
Note: Although the above discusses 'container images', really we are just
talking about files arranged in a well known manner and/or accessible
behind the well known REST APIs of the registries. Container registries are
often implemented using artifact management systems, such as Artifactory
and Nexus. We can think of a container registry as analogous to a Maven
repository in that artifacts are laid out in a common format.
GitHub Packages is a product offering from GitHub to provide storage and
publication of various artifacts (packages). The GitHub Container Registry
is a component of that product offering.
When choosing a place to publish OFBiz container images to, I considered
Docker Hub, the Apache Foundation's Artifactory instance and GitHub
Packages.
There was sufficient friction to getting up and running publishing to
Docker Hub. I would have needed assistance from INFRA, and documentation
wasn't clear on precisely what information/support I would have needed to
request.
Plus, the recent policy changes from Docker Inc meant I didn't want to
expend too much effort there.
GitHub packages seemed a nice low-friction direction to go in as it
integrated well with GitHub Actions. It also appeared to be growing in
recognition as a location to publish container image.
During the GitHub Actions build of the OFBiz container images (see
.github/workflows/docker-image.yml), we use the docker/login-action to log
in to ghcr.io (GitHub Packages Container Registry). The login makes use of
the GITHUB_TOKEN secret which is included by default in the workflow. No
additional configuration or permissions were required to access the
registry.
Later in the workflow, we use the docker/build-push-action to create the
docker image and push to ghcr.io.
We do not publish the OFBiz container images to DockerHub. However we do
build our container images based on the eclipse-temurin:17 image.
Since the image 'eclipse-temurin:17' identifier does not include a
hostname, the default hostname of registry-1.docker.io (i.e. Docker Hub) is
used. We do therefore depend on an image from Docker Hub, although we could
explore whether eclipse-temurin is available from any other public
container registries and use that instead.
Hope that helps,
Dan.
On Wed, 29 Mar 2023 at 10:01, Jacques Le Roux <ja...@les7arts.com>
wrote:
> Daniel,
>
> I have another minor question: how works and special is
> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz ? I can't
> see it locally nor
> from https://github.com/apache/ofbiz-framework
> I guess it's not related to Docker Hub, right ?
>
> TIA
>
> Le 29/03/2023 à 09:33, Daniel Watford a écrit :
> > Hi Jacques,
> >
> > Answers to your questions below.
> >
> > 1 - Yes, we should wait to be sure that nothing has been broken by the
> move to a container deployment to trunk. If/when we are happy then we can
> > merge ofbiz-tools PR5 into master, bringing in and squashing the commits
> currently in the docker-experimental branch.
> >
> > If we discover an issue with docker-trunk we can revert. I decided to
> use a PR to capture the changes to make it a bit easier for folks without
> > access to ofbiz-vm1 to review.
> >
> > I have seen some errors in the logs related to lack of database
> connections, probably due to my use of a Postgres database for the
> demo-trunk
> > deployment. As I write this I realise that by using a postgres rather
> than the embedded Derby I have already failed in delivering a like-for-like
> > version of demo-trunk. If wanted by the dev community, I can switch
> demo-trunk to use Derby, but I think it is valuable to have an external
> database
> > deployment publicly visible.
> >
> > I will look into the errors in the logs soon.
> >
> >
> > 2 - I don't have a problem with using AsciiDoc instead of Markdown, I
> just haven't dealt with it myself yet.
> >
> > Perhaps someone else could convert that file for us. :)
> >
> > I agree that the content in DOCKER.md is not intended to form part of
> the official OFBiz documentation, but I imagine in the future we might want
> to
> > point potential users towards the container images as an unsupported
> convenience. In that case we would probably need to rework DOCKER.[md|adoc]
> to
> > give appropriate deployment guidance, perhaps with separate documents to
> explain the container build process.
> >
> >
> > 3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather
> than danwatford/ofbiz-framework was an oversight on my part. I'll get it
> > cleaned up.
> >
> > Thanks,
> >
> > Dan.
> >
> > On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
> >
> > Hi Daniel,
> >
> > First, thanks for all your work!
> >
> > I had a quick look and Solr demo is working as expected. We are not
> up to date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.
> >
> > Now, I have few questions/notes for you and the community. You
> mentioned in a previous email:
> >
> > Le 22/03/2023 à 17:49, Daniel Watford a écrit :
> >> If consensus is established, then changes shall be initially made
> in a way
> >> allowing them to be quickly reversed if needed. Once the demo-trunk
> site is
> >> observed as running correctly, and with refreshes applied daily,
> then more
> >> permanent changes can be applied to the demo VM and changes
> committed to
> >> https://github.com/apache/ofbiz-tools/tree/master/demo-backup
> accordingly.
> >
> > 1. I guess we should now wait for at least another day before
> merging the docker-experimental branch into ofbiz-tools, right?
> > 2. We switched from using Markdown to AsciiDoc. I just want to say
> that you created
> > https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md.
> I don't think it's an issue because we don't want to expose that in the
> > site, it's rather for Docker users, right?
> > 3. (unrelated to docker effort) I guess we should remove the
> https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, right?
> (there
> > are more docker unrelated branches to clean, I'll send another
> email for that)
> >
> > Again, thanks!
> >
> > Jacques
> >
> > Le 28/03/2023 à 18:09, Daniel Watford a écrit :
> >> Hello,
> >>
> >> Perhttps://issues.apache.org/jira/browse/OFBIZ-12786, the
> demo-trunk site
> >> is now hosted by a docker container running on
> VMofbiz-vm1.apache.org <http://ofbiz-vm1.apache.org>.
> >>
> >> The changes to the host are captured in PR,
> >> https://github.com/apache/ofbiz-tools/pull/5.
> >>
> >> The previous approach to demo-trunk deployment patched the solr
> plugin to
> >> set the solr URL tohttps://demo-trunk.ofbiz.apache.org/solr. You
> can view
> >> the patch here -
> >>
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
> >> .
> >>
> >> I believe I have configured the new demo-trunk container to produce
> the
> >> same solr url, but by using configuration rather than source code
> changes.
> >>
> >> I don't know much about the use of Solr in OFBiz so don't know how
> to check
> >> that the original demo-trunk behaviour has been maintained.
> >>
> >> Please could someone familiar with Solr in OFBiz take a look
> >> https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see
> if Solr
> >> is operating as expected.
> >>
> >> Thanks,
> >>
> >> Dan.
> >>
> >
> >
> > --
> > Daniel Watford
--
Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Daniel,
I have another minor question: how works and special is https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz ? I can't see it locally nor
from https://github.com/apache/ofbiz-framework
I guess it's not related to Docker Hub, right ?
TIA
Le 29/03/2023 à 09:33, Daniel Watford a écrit :
> Hi Jacques,
>
> Answers to your questions below.
>
> 1 - Yes, we should wait to be sure that nothing has been broken by the move to a container deployment to trunk. If/when we are happy then we can
> merge ofbiz-tools PR5 into master, bringing in and squashing the commits currently in the docker-experimental branch.
>
> If we discover an issue with docker-trunk we can revert. I decided to use a PR to capture the changes to make it a bit easier for folks without
> access to ofbiz-vm1 to review.
>
> I have seen some errors in the logs related to lack of database connections, probably due to my use of a Postgres database for the demo-trunk
> deployment. As I write this I realise that by using a postgres rather than the embedded Derby I have already failed in delivering a like-for-like
> version of demo-trunk. If wanted by the dev community, I can switch demo-trunk to use Derby, but I think it is valuable to have an external database
> deployment publicly visible.
>
> I will look into the errors in the logs soon.
>
>
> 2 - I don't have a problem with using AsciiDoc instead of Markdown, I just haven't dealt with it myself yet.
>
> Perhaps someone else could convert that file for us. :)
>
> I agree that the content in DOCKER.md is not intended to form part of the official OFBiz documentation, but I imagine in the future we might want to
> point potential users towards the container images as an unsupported convenience. In that case we would probably need to rework DOCKER.[md|adoc] to
> give appropriate deployment guidance, perhaps with separate documents to explain the container build process.
>
>
> 3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather than danwatford/ofbiz-framework was an oversight on my part. I'll get it
> cleaned up.
>
> Thanks,
>
> Dan.
>
> On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux <ja...@les7arts.com> wrote:
>
> Hi Daniel,
>
> First, thanks for all your work!
>
> I had a quick look and Solr demo is working as expected. We are not up to date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.
>
> Now, I have few questions/notes for you and the community. You mentioned in a previous email:
>
> Le 22/03/2023 à 17:49, Daniel Watford a écrit :
>> If consensus is established, then changes shall be initially made in a way
>> allowing them to be quickly reversed if needed. Once the demo-trunk site is
>> observed as running correctly, and with refreshes applied daily, then more
>> permanent changes can be applied to the demo VM and changes committed to
>> https://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly.
>
> 1. I guess we should now wait for at least another day before merging the docker-experimental branch into ofbiz-tools, right?
> 2. We switched from using Markdown to AsciiDoc. I just want to say that you created
> https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md. I don't think it's an issue because we don't want to expose that in the
> site, it's rather for Docker users, right?
> 3. (unrelated to docker effort) I guess we should remove the https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, right? (there
> are more docker unrelated branches to clean, I'll send another email for that)
>
> Again, thanks!
>
> Jacques
>
> Le 28/03/2023 à 18:09, Daniel Watford a écrit :
>> Hello,
>>
>> Perhttps://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site
>> is now hosted by a docker container running on VMofbiz-vm1.apache.org <http://ofbiz-vm1.apache.org>.
>>
>> The changes to the host are captured in PR,
>> https://github.com/apache/ofbiz-tools/pull/5.
>>
>> The previous approach to demo-trunk deployment patched the solr plugin to
>> set the solr URL tohttps://demo-trunk.ofbiz.apache.org/solr. You can view
>> the patch here -
>> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
>> .
>>
>> I believe I have configured the new demo-trunk container to produce the
>> same solr url, but by using configuration rather than source code changes.
>>
>> I don't know much about the use of Solr in OFBiz so don't know how to check
>> that the original demo-trunk behaviour has been maintained.
>>
>> Please could someone familiar with Solr in OFBiz take a look
>> https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr
>> is operating as expected.
>>
>> Thanks,
>>
>> Dan.
>>
>
>
> --
> Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 29/03/2023 à 09:33, Daniel Watford a écrit :
> I agree that the content in DOCKER.md is not intended to form part of the official OFBiz documentation, but I imagine in the future we might want to
> point potential users towards the container images as an unsupported convenience. In that case we would probably need to rework DOCKER.[md|adoc] to
> give appropriate deployment guidance, perhaps with separate documents to explain the container build process.
We may wait that to migrate to .adoc
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Jacques,
Answers to your questions below.
1 - Yes, we should wait to be sure that nothing has been broken by the move
to a container deployment to trunk. If/when we are happy then we can merge
ofbiz-tools PR5 into master, bringing in and squashing the commits
currently in the docker-experimental branch.
If we discover an issue with docker-trunk we can revert. I decided to use a
PR to capture the changes to make it a bit easier for folks without access
to ofbiz-vm1 to review.
I have seen some errors in the logs related to lack of database
connections, probably due to my use of a Postgres database for the
demo-trunk deployment. As I write this I realise that by using a postgres
rather than the embedded Derby I have already failed in delivering a
like-for-like version of demo-trunk. If wanted by the dev community, I can
switch demo-trunk to use Derby, but I think it is valuable to have an
external database deployment publicly visible.
I will look into the errors in the logs soon.
2 - I don't have a problem with using AsciiDoc instead of Markdown, I just
haven't dealt with it myself yet.
Perhaps someone else could convert that file for us. :)
I agree that the content in DOCKER.md is not intended to form part of the
official OFBiz documentation, but I imagine in the future we might want to
point potential users towards the container images as an unsupported
convenience. In that case we would probably need to rework DOCKER.[md|adoc]
to give appropriate deployment guidance, perhaps with separate documents to
explain the container build process.
3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather than
danwatford/ofbiz-framework was an oversight on my part. I'll get it cleaned
up.
Thanks,
Dan.
On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux <ja...@les7arts.com>
wrote:
> Hi Daniel,
>
> First, thanks for all your work!
>
> I had a quick look and Solr demo is working as expected. We are not up to
> date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.
>
> Now, I have few questions/notes for you and the community. You mentioned
> in a previous email:
> Le 22/03/2023 à 17:49, Daniel Watford a écrit :
>
> If consensus is established, then changes shall be initially made in a way
> allowing them to be quickly reversed if needed. Once the demo-trunk site is
> observed as running correctly, and with refreshes applied daily, then more
> permanent changes can be applied to the demo VM and changes committed tohttps://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly.
>
>
> 1. I guess we should now wait for at least another day before merging
> the docker-experimental branch into ofbiz-tools, right?
> 2. We switched from using Markdown to AsciiDoc. I just want to say
> that you created
> https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md. I
> don't think it's an issue because we don't want to expose that in the site,
> it's rather for Docker users, right?
> 3. (unrelated to docker effort) I guess we should remove the
> https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch,
> right? (there are more docker unrelated branches to clean, I'll send
> another email for that)
>
> Again, thanks!
>
> Jacques
> Le 28/03/2023 à 18:09, Daniel Watford a écrit :
>
> Hello,
>
> Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site
> is now hosted by a docker container running on VM ofbiz-vm1.apache.org.
>
> The changes to the host are captured in PR,https://github.com/apache/ofbiz-tools/pull/5.
>
> The previous approach to demo-trunk deployment patched the solr plugin to
> set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can view
> the patch here -https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
> .
>
> I believe I have configured the new demo-trunk container to produce the
> same solr url, but by using configuration rather than source code changes.
>
> I don't know much about the use of Solr in OFBiz so don't know how to check
> that the original demo-trunk behaviour has been maintained.
>
> Please could someone familiar with Solr in OFBiz take a lookhttps://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr
> is operating as expected.
>
> Thanks,
>
> Dan.
>
>
>
--
Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Daniel,
First, thanks for all your work!
I had a quick look and Solr demo is working as expected. We are not up to date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.
Now, I have few questions/notes for you and the community. You mentioned in a previous email:
Le 22/03/2023 à 17:49, Daniel Watford a écrit :
> If consensus is established, then changes shall be initially made in a way
> allowing them to be quickly reversed if needed. Once the demo-trunk site is
> observed as running correctly, and with refreshes applied daily, then more
> permanent changes can be applied to the demo VM and changes committed to
> https://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly.
1. I guess we should now wait for at least another day before merging the docker-experimental branch into ofbiz-tools, right?
2. We switched from using Markdown to AsciiDoc. I just want to say that you created https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md. I
don't think it's an issue because we don't want to expose that in the site, it's rather for Docker users, right?
3. (unrelated to docker effort) I guess we should remove the https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, right? (there are
more docker unrelated branches to clean, I'll send another email for that)
Again, thanks!
Jacques
Le 28/03/2023 à 18:09, Daniel Watford a écrit :
> Hello,
>
> Perhttps://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site
> is now hosted by a docker container running on VM ofbiz-vm1.apache.org.
>
> The changes to the host are captured in PR,
> https://github.com/apache/ofbiz-tools/pull/5.
>
> The previous approach to demo-trunk deployment patched the solr plugin to
> set the solr URL tohttps://demo-trunk.ofbiz.apache.org/solr. You can view
> the patch here -
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch
> .
>
> I believe I have configured the new demo-trunk container to produce the
> same solr url, but by using configuration rather than source code changes.
>
> I don't know much about the use of Solr in OFBiz so don't know how to check
> that the original demo-trunk behaviour has been maintained.
>
> Please could someone familiar with Solr in OFBiz take a look
> https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr
> is operating as expected.
>
> Thanks,
>
> Dan.
>