{"id":20895,"date":"2022-12-03T11:04:00","date_gmt":"2022-12-03T10:04:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=20895"},"modified":"2026-02-25T21:35:25","modified_gmt":"2026-02-25T20:35:25","slug":"documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/","title":{"rendered":"Documentum – xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore"},"content":{"rendered":"\n

A few weeks ago, I faced an issue at a customer where xPlore PrimaryDsearch would stop responding to curl\/wget\/browser requests from time to time. The impacted environments were containers (pods) hosted on Kubernetes. At this customer, we were in progress of migrating their standalone xPlore installations (also on pods) to Multi-Node, meaning that before, there was only 1 pod containing a PrimaryDsearch+IndexAgent and after, there is a pod containing a PrimaryDsearch, another one with an IndexAgent and then several other pods with CPS Only instances.<\/p>\n\n\n\n

All these pods have liveness checks (readiness too but it’s irrelevant here) that basically perform a small wget to make sure the installed component(s) in the pod is(are) responding in a timely manner. A few working days after the end of the xPlore migration to the Multi-Node installation (well after the migration of the 1st Federation, there are 2 Federations for HA and to avoid downtime during such activities), some of the pods containing a PrimaryDsearch would suddenly restart a few times a day, while some others wouldn’t restart at all. After some quick checks, it was the liveness that was failing, meaning that three consecutive checks (executed every 10s) were timing out.<\/p>\n\n\n\n

This same liveness check is in place since years and xPlore would always respond in around 20-30ms, so this issue happening only on some of the Productive environments (2 out 10) was a little strange. To confirm this behavior, I executed the same wget command from the liveness check (with a slightly higher timeout of 30s instead of 3s) and recorded the execution time taken to be able to process\/analyze all the data after a restart of the pod:<\/p>\n\n\n

\n[xplore@ds1-0 ~]$ ## Before issue\n[xplore@ds1-0 ~]$ ## Triggering loop to monitor the response time of xPlore Dsearch UI\n[xplore@ds1-0 ~]$ echo; while true; do\n  time timeout 30s wget -q --spider --no-check-certificate --no-proxy https:\/\/localhost:9302\/dsearch\n  date\n  echo\n  sleep 10\ndone > \/data\/mop_`hostname -s`.log 2>&1\n\ncommand terminated with exit code 137\n[morgan@k8s_m1 ~]$\n####\n####\n[xplore@ds1-0 ~]$ ## After issue\n[xplore@ds1-0 ~]$ ## Analysis of the execution time\n[xplore@ds1-0 ~]$ echo; \\\necho " -- Nb wget with response < 1s: $(grep 'real.*0m0' \/data\/mop_`hostname -s`.log | wc -l)"; echo; \\\necho " -- Nb wget with response > 1s: $(grep 'real.*0m[1-9]' \/data\/mop_`hostname -s`.log | wc -l)"; \\\nawk '\/^real\/ {a=$0; getline; getline; getline; print $0 "  --  " a;}' \/data\/mop_`hostname -s`.log | grep "real.*0m[1-9]"; echo\n\n -- Nb wget with response < 1s: 2309\n\n -- Nb wget with response > 1s: 27\nFri Nov 11 08:32:09 UTC 2022  --  real  0m3.468s\nFri Nov 11 09:06:47 UTC 2022  --  real  0m2.986s\nFri Nov 11 09:07:20 UTC 2022  --  real  0m22.783s\nFri Nov 11 09:07:32 UTC 2022  --  real  0m2.606s\nFri Nov 11 09:07:51 UTC 2022  --  real  0m8.395s\nFri Nov 11 09:18:16 UTC 2022  --  real  0m18.204s\nFri Nov 11 09:25:21 UTC 2022  --  real  0m1.387s\nFri Nov 11 09:31:04 UTC 2022  --  real  0m9.129s\nFri Nov 11 10:41:48 UTC 2022  --  real  0m9.055s\nFri Nov 11 10:43:38 UTC 2022  --  real  0m8.167s\nFri Nov 11 10:54:31 UTC 2022  --  real  0m4.019s\nFri Nov 11 11:03:27 UTC 2022  --  real  0m1.082s\nFri Nov 11 11:04:40 UTC 2022  --  real  0m1.334s\nFri Nov 11 11:05:53 UTC 2022  --  real  0m1.095s\nFri Nov 11 11:06:05 UTC 2022  --  real  0m2.755s\nFri Nov 11 13:20:03 UTC 2022  --  real  0m1.916s\nFri Nov 11 14:14:54 UTC 2022  --  real  0m21.306s\nFri Nov 11 14:15:05 UTC 2022  --  real  0m1.506s\nFri Nov 11 14:15:46 UTC 2022  --  real  0m30.003s\nFri Nov 11 14:16:26 UTC 2022  --  real  0m30.007s\nFri Nov 11 14:16:56 UTC 2022  --  real  0m20.026s\nFri Nov 11 14:17:36 UTC 2022  --  real  0m30.003s\nFri Nov 11 14:18:16 UTC 2022  --  real  0m30.003s\nFri Nov 11 14:18:56 UTC 2022  --  real  0m30.002s\nFri Nov 11 14:19:36 UTC 2022  --  real  0m30.002s\nFri Nov 11 14:20:16 UTC 2022  --  real  0m30.002s\nFri Nov 11 14:20:56 UTC 2022  --  real  0m30.002s\n\n[xplore@ds1-0 data]$\n<\/pre><\/div>\n\n\n
As you can see above, the small monitoring command was running for around 6.5h (~2350 checks, every 10s) and 98.8% of the checks were properly replying in under 1s (the expected response time being ~0.030s), but during that time, there was still some checks that were significantly slower. However, the pod didn’t restart because there weren’t 3 consecutive liveness checks in failure. It’s only starting at 14:15 UTC that the response time was consistently at 30s (timeout), meaning that xPlore wasn’t responding at all.<\/p>\n\n\n\n
At the same time, I was thinking at what exactly the reason for xPlore to stop responding could be and the first thing that came to my mind was that WildFly could be running out of threads. Therefore, it wouldn’t reply because all the threads would be used by ongoing activities (indexing & searches). To validate this assumption, I launched another small command that would retrieve the Java PID and then perform a thread dump every 30s, so that I could correlate the thread dumps with the xPlore response time and hopefully find what is happening:<\/p>\n\n\n
\n[xplore@ds1-0 ~]$ ## Before issue\n[xplore@ds1-0 ~]$ ## Triggering loop to monitor the threads\n[xplore@ds1-0 ~]$ echo; while true; do\n  d=$(date "+%Y-%m-%d_%H-%M-%S")\n  dh=${d::13}\n  mkdir -p \/data\/threads_${dh}\n  jcmd $(pgrep -f "java.*DctmServer_PrimaryDsearch") Thread.print > \/data\/threads_${dh}\/${d}.log 2>&1\n  sleep 30\ndone\n\ncommand terminated with exit code 137\n[morgan@k8s_m1 ~]$\n<\/pre><\/div>\n\n\n
As shown previously, the issue started around 14:15 UTC. Therefore, I defined 2 periods across 8 threads each (~3.5min), to analyze the thread dumps before (14:10:42 to 14:14:14<\/em>) and while the issue appeared (14:14:14 to 14:17:46<\/em>), respectively. Using the online tool FastThread<\/a> (please see below the reports generated by fastthread.io), to do the analysis of thread dumps, it\u2019s clear that the issue is present because of the “default task<\/em>” threads. While there are 16 of them (it\u2019s really not a lot), most of these were “WAITING<\/em>” under normal behavior and when xPlore wasn’t responding, all these were “TIMED_WAITING<\/em>“:<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
When looking at the thread dump in details, it was clear that:<\/p>\n\n\n\n
    \n
  1. “WAITING<\/em>” status is when the thread isn’t doing anything, because the stack is very short (~10 lines), and it’s generic<\/li>\n\n\n\n
  2. “TIMED_WAITING<\/em>” status is when the thread is doing something, because the stack is longer (~40\/50 lines), and it usually contains things like “at c.e.d.c.f.i.c.h.impl.SearchQueryHandler<\/strong>.executeAction<\/strong>(SearchQueryHandler.java:21)” or “at c.e.d.c.f.i.c.i.ESSIndexServer<\/strong>.waitForUpdates<\/strong>(ESSIndexServer.java:456)”<\/li>\n<\/ol>\n\n\n\n
    The thread dumps confirmed the assumption that xPlore PrimaryDsearch isn’t responding simply because it is running out of available threads to process the request. Going deeper in that direction, the number of worker threads that WildFly uses is defined using the “task-max-threads<\/em>” parameter of the worker inside the “standalone.xml<\/em>” file. OpenText do not set any value for that parameter since the definition is simply: ‘<worker name=”default”\/><\/em>‘. Therefore, based on the documentation<\/a> (it’s for version 19 but you get the idea)), if nothing is specified, WildFly will use a default of “cpuCount*16<\/em>“.<\/p>\n\n\n\n
    The Kubernetes Node on which this pod was running was a VM with 1 physical CPU (1 socket) and 16 vCPU. Before the migration to Multi-Node, the xPlore containers had a limit set to 6 CPUs but for the migration, the limit wasn\u2019t set, to allow xPlore to use whatever is available during the full reindex. If the documentation of WildFly is correct, from my point of view, it means that there should be 16*16=256 worker threads, since it would, I assume, take the number of CPUs available at the VM\/OS. But it was stuck at 16 in our case and that didn’t make too much sense to me.<\/p>\n\n\n\n
    Initially, I thought that WildFly was using the “1 socket” to define the amount of worker threads, but after a test on DEV on a Node having 2 sockets and 32 vCPU, it was still using only 16 worker threads in the same conditions. Even though the xPlore container itself had no request\/limit, but the pod had 3 containers (1 for xPlore and 2 sidecar containers for monitoring) and the 2 sidecars did, still, have their limits in place (0.1 CPU), since we only wanted to allow the main xPlore container to run wild. I thought that maybe the sidecar containers would be the reason why it is assuming that there is only 1 CPU (and hence uses 16 worker threads). Maybe it would sum-up all the limits and then use this value or divide it by the number of containers or maybe it would take the max limit of the pod (from any containers). So, I did a lot of tests to check what was true and what was really happening. In summary, it doesn’t seem to be any of the above. Whatever is happening on the sidecar or on the K8s Node has no relation to the number of WildFly worker threads, only the container’s requests\/limits matters (as it should):<\/p>\n\n\n\n
    Requests \/ Limits<\/td>WildFly worker threads<\/td><\/tr>
    No request\/limit set on any containers<\/td>16<\/td><\/tr>
    Request\/limit set on sidecar (any value)
    No request\/limit set on WildFly container<\/td>    		16<\/td><\/tr>
    Request\/limit set on sidecar (any value)
    Request set to 1.5<\/strong> CPU on WildFly container<\/td>    		32 (2*16)<\/td><\/tr>
    Request\/limit set on sidecar (any value)
    Request set to 2 CPU and limit set to 4.1<\/strong> CPU on WildFly container<\/td>    		80 (5*1.6)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Therefore, it looks like the number of WildFly worker threads, if there is no “task-max-threads<\/em>” parameter defined, will be: MAX(1, ROUNDUP(Request_CPU,0), ROUNDUP(Limit_CPU,0)) * 16<\/strong>. If you aren’t familiar with excel formulas or if you simply don’t understand what I meant by that, it does the following: it will round up (always up, never down) the Request and Limit CPU value to the integer (e.g.:<\/em> 2 remains 2 but 2.1 becomes 3) and then it will multiply 16 by the maximum value between 1, the rounded value for the request and the rounded value for the limit.<\/p>\n\n\n\n
    To be able to retrieve these details, I simply updated the limits, waited for the pod to be re-created and once xPlore was running again, I launched a bunch of HTTP requests (wget or browser for example) until the value reached its maximum:<\/p>\n\n\n
    \n[morgan@k8s_m1 ~]$ ## xPlore container with 2 CPU (limit)\n[morgan@k8s_m1 ~]$ kubectl describe pod ds1-0 | grep -A1 -B10 "Limits:" | grep -E "^  [a-z]|cpu:"\n  ds:\n      cpu:     2\n  grok:\n      cpu:     100m\n  procexp:\n      cpu:     100m\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'echo; PID=$(pgrep -o -f "java.*DctmServer_PrimaryDsearch"); jcmd ${PID} Thread.print > \/tmp\/mop.txt; echo "Nb worker threads: `grep "default task" \/tmp\/mop.txt | wc -l`"; rm \/tmp\/mop.txt; echo;'\n\nNb worker threads: 7\n\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'for i in $(seq 1 50); do timeout 1s wget -q --spider --no-check-certificate --no-proxy https:\/\/localhost:9302\/dsearch; done'\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'echo; PID=$(pgrep -o -f "java.*DctmServer_PrimaryDsearch"); jcmd ${PID} Thread.print > \/tmp\/mop.txt; echo "Nb worker threads: `grep "default task" \/tmp\/mop.txt | wc -l`"; rm \/tmp\/mop.txt; echo;'\n\nNb worker threads: 32\n\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$ ## xPlore container with 3.1 CPU (limit)\n[morgan@k8s_m1 ~]$ kubectl describe pod ds1-0 | grep -A1 -B10 "Limits:" | grep -E "^  [a-z]|cpu:"\n  ds:\n      cpu:     3100m\n  grok:\n      cpu:     1100m\n  procexp:\n      cpu:     2100m\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'echo; PID=$(pgrep -o -f "java.*DctmServer_PrimaryDsearch"); jcmd ${PID} Thread.print > \/tmp\/mop.txt; echo "Nb worker threads: `grep "default task" \/tmp\/mop.txt | wc -l`"; rm \/tmp\/mop.txt; echo;'\n\nNb worker threads: 9\n\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'for i in $(seq 1 75); do timeout 1s wget -q --spider --no-check-certificate --no-proxy https:\/\/localhost:9302\/dsearch; done'\n[morgan@k8s_m1 ~]$\n[morgan@k8s_m1 ~]$ kubectl exec -it ds1-0 -c ds -- bash -l -c 'echo; PID=$(pgrep -o -f "java.*DctmServer_PrimaryDsearch"); jcmd ${PID} Thread.print > \/tmp\/mop.txt; echo "Nb worker threads: `grep "default task" \/tmp\/mop.txt | wc -l`"; rm \/tmp\/mop.txt; echo;'\n\nNb worker threads: 64\n\n[morgan@k8s_m1 ~]$\n<\/pre><\/div>\n\n\n
    As a conclusion, it is very important to have at least a request or a limit set for Documentum containers using WildFly (JMS before Dctm 21.x and xPlore). If you do not want to set either of these, you will most probably need to manually define the “task-max-threads<\/em>” parameter, so that WildFly starts with enough worker threads. Having 16 worker threads might be enough for some use-cases but it\u2019s going to be filled quite easily if there are a lot of searches being done in parallel.<\/p>\n\n\n\n
    Note:<\/em> on WildFly9 (Documentum 16.4 defaults to wildfly9.0.1), the number of “default task<\/em>” present in the thread dump will only increase, up to the maximum value defined (or the default value). On WildFly17 (Documentum 20.2 defaults to wildfly17.0.1), it behaves differently, the value of “default task<\/em>” will have a minimum of 2 it seems, and it will increase when needed but then decrease again. Therefore, on WildFly9, you can easily find the max value used by simply launching dozens of HTTP requests. When xPlore 16.4 starts for example, it should have around 7\/8 “default task<\/em>” and then triggering 50 HTTP requests will lead to a value of 16 or 32 or 48 or whatever, depending on the number of CPUs that are configured. On WildFly17, it will stay at 2. You might see it increase temporarily to 3 or 4 if you are launching a lot of such requests in parallel but it won’t continue to increase, it will go back to 2 afterwards.<\/p>\n","protected":false},"excerpt":{"rendered":"
    A few weeks ago, I faced an issue at a customer where xPlore PrimaryDsearch would stop responding to curl\/wget\/browser requests from time to time. The impacted environments were containers (pods) hosted on Kubernetes. At this customer, we were in progress of migrating their standalone xPlore installations (also on pods) to Multi-Node, meaning that before, there […]<\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[197,525],"tags":[423,2769,2609,903,2076,1100,2768,474],"type_dbi":[],"class_list":["post-20895","post","type-post","status-publish","format-standard","hentry","category-application-integration-middleware","category-enterprise-content-management","tag-cpu","tag-default-task","tag-documentum-2","tag-jms","tag-threads","tag-wildfly","tag-worker","tag-xplore"],"acf":[],"yoast_head":"\nDocumentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Documentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore\" \/>\n<meta property=\"og:description\" content=\"A few weeks ago, I faced an issue at a customer where xPlore PrimaryDsearch would stop responding to curl\/wget\/browser requests from time to time. The impacted environments were containers (pods) hosted on Kubernetes. At this customer, we were in progress of migrating their standalone xPlore installations (also on pods) to Multi-Node, meaning that before, there […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2022-12-03T10:04:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-25T20:35:25+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1496\" \/>\n\t<meta property=\"og:image:height\" content=\"474\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Morgan Patou\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@MorganPatou\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Morgan Patou\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\"},\"author\":{\"name\":\"Morgan Patou\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"headline\":\"Documentum – xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore\",\"datePublished\":\"2022-12-03T10:04:00+00:00\",\"dateModified\":\"2026-02-25T20:35:25+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\"},\"wordCount\":1496,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png\",\"keywords\":[\"CPU\",\"default task\",\"Documentum\",\"jms\",\"threads\",\"WildFly\",\"worker\",\"xPlore\"],\"articleSection\":[\"Application integration & Middleware\",\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\",\"name\":\"Documentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png\",\"datePublished\":\"2022-12-03T10:04:00+00:00\",\"dateModified\":\"2026-02-25T20:35:25+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png\",\"width\":1496,\"height\":474},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Documentum – xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\",\"name\":\"Morgan Patou\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"caption\":\"Morgan Patou\"},\"description\":\"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\/Banking, and the Pharmaceutical industry.\",\"sameAs\":[\"https:\/\/blog.dbi-services.com\/author\/morgan-patou\/\",\"https:\/\/x.com\/MorganPatou\"],\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/morgan-patou\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Documentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/","og_locale":"en_US","og_type":"article","og_title":"Documentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore","og_description":"A few weeks ago, I faced an issue at a customer where xPlore PrimaryDsearch would stop responding to curl\/wget\/browser requests from time to time. The impacted environments were containers (pods) hosted on Kubernetes. At this customer, we were in progress of migrating their standalone xPlore installations (also on pods) to Multi-Node, meaning that before, there […]","og_url":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/","og_site_name":"dbi Blog","article_published_time":"2022-12-03T10:04:00+00:00","article_modified_time":"2026-02-25T20:35:25+00:00","og_image":[{"width":1496,"height":474,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png","type":"image\/png"}],"author":"Morgan Patou","twitter_card":"summary_large_image","twitter_creator":"@MorganPatou","twitter_misc":{"Written by":"Morgan Patou","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/"},"author":{"name":"Morgan Patou","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"headline":"Documentum – xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore","datePublished":"2022-12-03T10:04:00+00:00","dateModified":"2026-02-25T20:35:25+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/"},"wordCount":1496,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png","keywords":["CPU","default task","Documentum","jms","threads","WildFly","worker","xPlore"],"articleSection":["Application integration & Middleware","Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/","url":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/","name":"Documentum - xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png","datePublished":"2022-12-03T10:04:00+00:00","dateModified":"2026-02-25T20:35:25+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/12\/thread_details_p1.png","width":1496,"height":474},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-primarydsearch-not-responding-to-curl-wget-browser-requests-anymore\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Documentum – xPlore PrimaryDsearch not responding to curl\/wget\/browser requests anymore"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8","name":"Morgan Patou","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","caption":"Morgan Patou"},"description":"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\/Banking, and the Pharmaceutical industry.","sameAs":["https:\/\/blog.dbi-services.com\/author\/morgan-patou\/","https:\/\/x.com\/MorganPatou"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/morgan-patou\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/20895","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=20895"}],"version-history":[{"count":10,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/20895\/revisions"}],"predecessor-version":[{"id":43189,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/20895\/revisions\/43189"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=20895"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=20895"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=20895"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=20895"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}