{"id":29774,"date":"2023-12-14T16:52:13","date_gmt":"2023-12-14T15:52:13","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=29774"},"modified":"2023-12-14T16:52:15","modified_gmt":"2023-12-14T15:52:15","slug":"documentum-xplore-cps-temporary-folder-not-being-cleaned-properly","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/","title":{"rendered":"Documentum – xPlore CPS temporary folder not being cleaned properly"},"content":{"rendered":"\n

At a customer using Documentum inside Kubernetes, unusually frequent restarts of xPlore containers were noted a couple weeks after the introduction of CPS Only pods on the different Production environments. The customer had a very simple Standalone xPlore setup, with Dsearch+IndexAgent, but without CPS Only Nodes. It was noticed at this customer that the indexing and search load was reaching the limit of what the then-current setup could handle. Therefore, to increase the processing power of xPlore, it was decided to switch to a Multi-Node setup, with a few additional CPS, depending on the environment.<\/p>\n\n\n\n

No issues were found on DEV and QA environments, everything was working properly with the newly added CPS. It’s only after a couple weeks running on Production that the first unusual restart happened. At first glance, it looked like it could have been an issue with the container layers since alerts were being receiving related to file system almost full for the path containing the container’s local volumes\/layers and a few minutes later, there would be a restart of some containers, mostly xPlore Dsearch\/CPS pods but not only.<\/p>\n\n\n\n

After some more investigation, it was seen that the issue was caused by the CPS temporary folder of xPlore being filled with quite a bunch of 400Mb files. Since this path wasn’t using a Persistent Volume, it was therefore using the local container’s storage, which explained the file system full alerts. Once the Kubernetes Worker’s disk for the container’s local volumes\/layers would reach its maximum size of 200Gb, then the container engine would kill some containers to free some space, hence the unusual restarts.<\/p>\n\n\n\n

These were some of the files in question:<\/p>\n\n\n

\n[xplore@ds1-0 ~]$ cd $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin\/temp\n[xplore@ds1-0 temp]$ ls -ltr\ntotal 157286400\n...\n-rw-r----- 1 xplore xplore  408584192 Dec 19 01:25 SSS4AE9\n-rw-r----- 1 xplore xplore  409419776 Dec 19 01:27 SSSE305\n-rw-r----- 1 xplore xplore  412467200 Dec 19 01:27 SSS652A\n-rw-r----- 1 xplore xplore  413335552 Dec 19 01:28 SSS48F\n-rw-r----- 1 xplore xplore  482869248 Dec 19 01:31 SSSC206\n-rw-r----- 1 xplore xplore  397770752 Dec 19 01:32 SSSB62C\n[xplore@ds1-0 temp]$ date\nMon Dec 19 10:02:02 UTC 2022\n[xplore@ds1-0 temp]$\n<\/pre><\/div>\n\n\n
The CPS configuration used was pretty simple, similar to the out-of-the-box one. A few changes made for indexing of large files, for exports paths and increasing the daemon_count from 3 to 5, for example. Moreover, the configuration file wasn’t touched for months:<\/p>\n\n\n
\n[xplore@ds1-0 temp]$ grep daemon_count $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/PrimaryDsearch_local_configuration.xml\n <daemon_count>5<\/daemon_count>\n <query_dedicated_daemon_count>1<\/query_dedicated_daemon_count>\n[xplore@ds1-0 temp]$\n[xplore@ds1-0 temp]$ grep temp $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/PrimaryDsearch_local_configuration.xml\n    <temp_directory>temp<\/temp_directory>\n    <keep_temp_file>false<\/keep_temp_file>\n    <temp_file_retain_time>900<\/temp_file_retain_time>\n                    <property name="temp_file_folder">temp<\/property>\n[xplore@ds1-0 temp]$\n<\/pre><\/div>\n\n\n
In case you don’t know, you can only have a maximum of 7 threads for the CPS daemon (daemon_count<\/em> + query_dedicated_daemon_count<\/em>) because you always need to keep the 8th thread available for restarts, c.f. KB0474159<\/a>. Here, there are 6 configured so it is properly under the threshold, which means that this isn’t the issue.<\/p>\n\n\n\n
While checking the CPS logs, it was seen that there was quite a bunch of CPS self-termination from time to time:<\/p>\n\n\n
\n[xplore@ds1-0 temp]$ cdlogs\n[xplore@ds1-0 logs]$ grep "2022-12-17.*Consumed memory.*larger than the threshold.*will self-terminate" cps_daemon.log | wc -l\n3\n[xplore@ds1-0 logs]$ grep "2022-12-18.*Consumed memory.*larger than the threshold.*will self-terminate" cps_daemon.log | wc -l\n237\n[xplore@ds1-0 logs]$ grep "2022-12-19.*Consumed memory.*larger than the threshold.*will self-terminate" cps_daemon.log | wc -l\n242\n[xplore@ds1-0 logs]$\n<\/pre><\/div>\n\n\n
To avoid issues over the Christmas period, a cronjob has been created that would perform the clean-up of the temp folder periodically. Based on the data from the logs and the temporary files on the file system, it appeared that the issue might be related to high indexing load scenarios. Therefore, to try to reproduce the issue, around 20 000 documents were submitted to indexing through a refeed task. These documents were selected using a command such as:<\/p>\n\n\n
\nselect\n  r_object_id\nfrom\n  dm_document\nwhere\n  r_modify_date >= date('10.01.2023 00:00:00 UTC','dd.mm.yyyy hh:mi:ss')\n  and r_modify_date < date('11.01.2023 00:00:00 UTC','dd.mm.yyyy hh:mi:ss');\n<\/pre><\/div>\n\n\n
With the refeed in progress, a few SSS* files appeared, and the CPS also crashed a few times, in the middle:<\/p>\n\n\n
\n[xplore@ds1-0 logs]$ cd $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin\/temp\n[xplore@ds1-0 temp]$ date; ls -ltr | tail -2\nThu Jan 12 08:42:41 UTC 2023\n-rw-r----- 1 xplore xplore 385859584 Jan 12 08:27 SSSDA50\n-rw-r----- 1 xplore xplore 383336448 Jan 12 08:29 SSSFAD5\n[xplore@ds1-0 temp]$\n[xplore@ds1-0 temp]$ stat SSSDA50\n File: \u2018SSSDA50\u2019\n Size: 385859584 Blocks: 756608 IO Block: 65536 regular file\nDevice: fbh\/251d Inode: 9247321667856512778 Links: 1\nAccess: (0640\/-rw-r-----) Uid: ( 514\/ xplore) Gid: ( 514\/ xplore)\nAccess: 2023-01-12 08:26:44.056715000 +0000\nModify: 2023-01-12 08:27:54.168722000 +0000\nChange: 2023-01-12 08:27:54.168722000 +0000\n Birth: -\n[xplore@ds1-0 temp]$\n[xplore@ds1-0 temp]$ stat SSSFAD5\n File: \u2018SSSFAD5\u2019\n Size: 383336448 Blocks: 751664 IO Block: 65536 regular file\nDevice: fbh\/251d Inode: 9247321667856512779 Links: 1\nAccess: (0640\/-rw-r-----) Uid: ( 514\/ xplore) Gid: ( 514\/ xplore)\nAccess: 2023-01-12 08:27:57.640918000 +0000\nModify: 2023-01-12 08:29:01.369706000 +0000\nChange: 2023-01-12 08:29:01.369706000 +0000\n Birth: -\n[xplore@ds1-0 temp]$\n[xplore@ds1-0 temp]$ cdlogs\n[xplore@ds1-0 logs]$ grep "Consumed memory.*larger than the threshold.*will self-terminate" cps_daemon.log | tail -2\n2023-01-12 08:27:53,794 WARN [Daemon3(22493)-Core-(140435641489152)] Consumed memory 4148326400, larger than the threshold 4000000000, Daemon3(22493) will self-terminate\n2023-01-12 08:29:01,044 WARN [RDaemon0(23282)-Core-(140654441674496)] Consumed memory 4092612608, larger than the threshold 4000000000, RDaemon0(23282) will self-terminate\n[xplore@ds1-0 logs]$\n<\/pre><\/div>\n\n\n
As you can see above, the timings are quite close. So close that it looks like a CPS would generate such SSS* file just before crashing\u2026 The CPS daemon has 4GB of RAM as memory threshold for its processing and the size of the SSS* files are all around 370-440Mb, so around 10% of that size. Could it be some kind of memory dump or something similar? The ticket CS0053875<\/em> has been opened with the OpenText support to try to find the root cause of these SSS* files but as of today, it’s still unclear what these files could be.<\/p>\n\n\n\n
As shown above, there are some parameters that control how files are created\/deleted for the CPS:<\/p>\n\n\n\n
    \n
  • temp_directory<\/em>: Folder under which the CPS temporary files will be stored, default to “temp” (i.e. $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/temp\/)<\/li>\n\n\n\n
  • keep_temp_file<\/em>: Whether to keep the CPS temporary files or not, default to “false” (i.e. don’t keep)<\/li>\n\n\n\n
  • temp_file_retain_time<\/em>: How long (in seconds) will the CPS temporary files be kept, default to “900” (i.e. 15 minutes) and only applies if “keep_temp_file” is “true”<\/li>\n\n\n\n
  • temp_file_folder<\/em>: Folder under which the CPS temporary format and language identification files will be stored, default to “temp” (i.e. $XPLORE_HOME\/dsearch\/cps\/cps_daemon\/temp\/)<\/li>\n<\/ul>\n\n\n\n
    That’s the theory. These details come from the Documentation of xPlore itself, but in reality, they do not appear to be fully accurate\u2026 While doing testing, we tried to use absolute paths in the CPS configuration file, instead of the default relative ones. By doing that, it looks like “temp_directory<\/em>” changes the location of the “dmftcontentref*<\/em>” files, while “temp_file_folder<\/em>” changes the location of the “SSS*” files. But as you saw above, the SSS* files weren’t created inside “$XPLORE_HOME\/dsearch\/cps\/cps_daemon\/temp\/” but inside “$XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin<\/span><\/strong>\/temp\/” (see the additional \/bin\/ in the path?). So, there is already something strange there with the real default value used by xPlore when it’s using a relative path.<\/p>\n\n\n\n
    A second strange point is that “temp_file_retain_time<\/em>” appears to be linked to the “temp_directory<\/em>” path but not “temp_file_folder<\/em>” because if you set the “keep_temp_file<\/em>” to true, then “dmftcontentref*<\/em>” files will stay for 15 minutes before being deleted but nothing will happen to “SSS*” files (if you are using their default relative “temp” value). So, the retain parameter appears to be working properly on that aspect. To continue with the testing, we tried to set both “temp_directory<\/em>” and “temp_file_folder<\/em>” to the same absolute folder, while keeping the default “keep_temp_file<\/em>” value of “false” (meaning don’t keep temporary files and therefore it shouldn’t perform the cleanup, since “temp_file_retain_time<\/em>” is supposed to not take effect). With that configuration, no “dmftcontentref*<\/em>” files were kept (expected behavior) while “SSS*” files would be created in the same folder and then removed after 15 minutes exactly\u2026 That means that contrary to the documentation, it appears that the cleanup is done after “temp_file_retain_time<\/em>” seconds, even if “keep_temp_file<\/em>” is set to “false”. Therefore, the documentation statement of “This parameter is only effective when keep_temp_file is set to false<\/em>” for “temp_file_retain_time<\/em>” doesn’t appear to be correct.<\/p>\n\n\n\n
    In conclusion, the temporary folder and more specifically the “SSS*” files can be cleaned by xPlore if you set the same absolute path, i.e., with this configuration:<\/p>\n\n\n
    \n[xplore@ds1-0 logs]$ cd $XPLORE_HOME\/dsearch\/cps\/cps_daemon\n[xplore@ds1-0 cps_daemon]$\n[xplore@ds1-0 cps_daemon]$ # Before \/ Default configuration\n[xplore@ds1-0 cps_daemon]$ config_file="PrimaryDsearch_local_configuration.xml"\n[xplore@ds1-0 cps_daemon]$\n[xplore@ds1-0 cps_daemon]$ grep temp ${config_file}\n    <temp_directory>temp<\/temp_directory>\n    <keep_temp_file>false<\/keep_temp_file>\n    <temp_file_retain_time>900<\/temp_file_retain_time>\n                    <property name="temp_file_folder">temp<\/property>\n[xplore@ds1-0 cps_daemon]$\n[xplore@ds1-0 cps_daemon]$\n[xplore@ds1-0 cps_daemon]$ # Changing default configuration\n[xplore@ds1-0 cps_daemon]$ cps_temp_path="$XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin\/temp"\n[xplore@ds1-0 cps_daemon]$ sed -i "s,<temp_directory>[^<]*<,<temp_directory>${cps_temp_path}<," ${config_file}\n[xplore@ds1-0 cps_daemon]$ sed -i "s,temp_file_folder\\">[^<]*<,temp_file_folder\\">${cps_temp_path}<," ${config_file}\n[xplore@ds1-0 cps_daemon]$\n[xplore@ds1-0 cps_daemon]$ grep temp ${config_file}\n    <temp_directory>$XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin\/temp<\/temp_directory>\n    <keep_temp_file>false<\/keep_temp_file>\n    <temp_file_retain_time>900<\/temp_file_retain_time>\n                    <property name="temp_file_folder">$XPLORE_HOME\/dsearch\/cps\/cps_daemon\/bin\/temp<\/property>\n[xplore@ds1-0 cps_daemon]$\n<\/pre><\/div>\n\n\n
    It’s definitively not a final solution since the temporary files are still being created for unknown reasons (sometimes with a CPS crash, sometimes without), but it’s a first step and it’s still better than having pods restart every few hours.<\/p>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    At a customer using Documentum inside Kubernetes, unusually frequent restarts of xPlore containers were noted a couple weeks after the introduction of CPS Only pods on the different Production environments. The customer had a very simple Standalone xPlore setup, with Dsearch+IndexAgent, but without CPS Only Nodes. It was noticed at this customer that the indexing […]<\/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":[525],"tags":[1894,1101,3196,2046,474],"type_dbi":[],"class_list":["post-29774","post","type-post","status-publish","format-standard","hentry","category-enterprise-content-management","tag-cleanup","tag-cps","tag-daemon","tag-query","tag-xplore"],"acf":[],"yoast_head":"\nDocumentum - xPlore CPS temporary folder not being cleaned properly - 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-cps-temporary-folder-not-being-cleaned-properly\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Documentum - xPlore CPS temporary folder not being cleaned properly\" \/>\n<meta property=\"og:description\" content=\"At a customer using Documentum inside Kubernetes, unusually frequent restarts of xPlore containers were noted a couple weeks after the introduction of CPS Only pods on the different Production environments. The customer had a very simple Standalone xPlore setup, with Dsearch+IndexAgent, but without CPS Only Nodes. It was noticed at this customer that the indexing […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2023-12-14T15:52:13+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-14T15:52:15+00:00\" \/>\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=\"5 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-cps-temporary-folder-not-being-cleaned-properly\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\"},\"author\":{\"name\":\"Morgan Patou\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"headline\":\"Documentum – xPlore CPS temporary folder not being cleaned properly\",\"datePublished\":\"2023-12-14T15:52:13+00:00\",\"dateModified\":\"2023-12-14T15:52:15+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\"},\"wordCount\":1144,\"commentCount\":0,\"keywords\":[\"cleanup\",\"CPS\",\"daemon\",\"query\",\"xPlore\"],\"articleSection\":[\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\",\"name\":\"Documentum - xPlore CPS temporary folder not being cleaned properly - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2023-12-14T15:52:13+00:00\",\"dateModified\":\"2023-12-14T15:52:15+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Documentum – xPlore CPS temporary folder not being cleaned properly\"}]},{\"@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 CPS temporary folder not being cleaned properly - 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-cps-temporary-folder-not-being-cleaned-properly\/","og_locale":"en_US","og_type":"article","og_title":"Documentum - xPlore CPS temporary folder not being cleaned properly","og_description":"At a customer using Documentum inside Kubernetes, unusually frequent restarts of xPlore containers were noted a couple weeks after the introduction of CPS Only pods on the different Production environments. The customer had a very simple Standalone xPlore setup, with Dsearch+IndexAgent, but without CPS Only Nodes. It was noticed at this customer that the indexing […]","og_url":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/","og_site_name":"dbi Blog","article_published_time":"2023-12-14T15:52:13+00:00","article_modified_time":"2023-12-14T15:52:15+00:00","author":"Morgan Patou","twitter_card":"summary_large_image","twitter_creator":"@MorganPatou","twitter_misc":{"Written by":"Morgan Patou","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/"},"author":{"name":"Morgan Patou","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"headline":"Documentum – xPlore CPS temporary folder not being cleaned properly","datePublished":"2023-12-14T15:52:13+00:00","dateModified":"2023-12-14T15:52:15+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/"},"wordCount":1144,"commentCount":0,"keywords":["cleanup","CPS","daemon","query","xPlore"],"articleSection":["Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/","url":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/","name":"Documentum - xPlore CPS temporary folder not being cleaned properly - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2023-12-14T15:52:13+00:00","dateModified":"2023-12-14T15:52:15+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-xplore-cps-temporary-folder-not-being-cleaned-properly\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Documentum – xPlore CPS temporary folder not being cleaned properly"}]},{"@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\/29774","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=29774"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/29774\/revisions"}],"predecessor-version":[{"id":29775,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/29774\/revisions\/29775"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=29774"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=29774"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=29774"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=29774"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}