I am not sure what the best way to provide a report about the file
differences. I can tell you a quick summary comparing a difference in
files between the old and new datastore:diff -qrN datastore/
datastore-bak/ | wc -l534635The AEM Usage Report
(/etc/reports/diskusage.html) is basically identical -- I do not have an
exact comparison on numbers, but the difference is negligible for our
Here is what I have done that seems to have resolved the issue. If
someone could let me know if there is some issue I am not seeing here
but otherwise, it seems to have worked beautifully.java -jar
--datastore=/content/backup/datastore/Running this command to pretend as
if I am upgrading, but using "segment-old" for source and target...
Unfortunately, I cannot do that since the server is remote and does not
have a display.Anything else I can try? I have even updated to Oak
1.4.24 on a cloned server and deleted indices and compacted twice. I
have not been able to free any space of the datastore. Is there some way
to clone the datastore through some command (maybe the oak-run jar) that
won't just copy byte-for-byte all the files on the disk and might
produce something trimmed down?
We have a cloned server already. So I stopped the application. I deleted
crx-quickstart/repository/index. I ran java -jar oak-run-1.4.17.jar
checkpoints /content/aem/crx-quickstart/repository/segmentstore/ rm-all.
I started the server. I waited for the index to be built. I ran garbage
collection. I checked the Disk Usage report. Still the same space is
used in the datastore on the disk and the disk usage report is still
showing the same, much lower number.
All files over 100 MB are zips. I have inspected one of the files over 6
GB. They look like packages that were backups, but these packages do not
exist anymore. I have checked all packages from the Package Explorer
multiple times to confirm. Is there something I can do about these files
in the meantime? Why would they not be garbage collected?This would be
helpful in cleaning up at least a few GB, but the question about the
over 150GB+ will still remain. 😕
Yes. I performed offline compaction. Then I did various ways of garbage
collection. I turned off the application, ran compaction, turned it on,
and ran garbage collection, including the following command which should
be clear that I have.curl -silent -u username:password -X POST --data
18:10:36.159 *INFO* [qtp1670602695-...
I appreciate the assistance, but it's not helpful if my message is not
read. We run garbage collection...daily.I have searched for hours before
posting and read all of Adobe's documentation on maintenance and many
articles on this forum. However, I will repeat that we run version
cleanup, workflow cleanup, and data store garbage collection daily. I
will also repeat we have performed compaction.The data store has grown
to this over 2 years or more, it is not suddenly growing rapidly, so a
We have an AEM 6.2 instance with Hotfix 17578 (cq-6.2.0-hotfix-17578)
installed so we are on Oak 1.4.17 and CFP18.We run garbage collection,
version cleanup, and workflow cleanup daily. We have a separate
datastore and segment store. We have performed offline compaction but
that only applies to the segmentstore.The disk usage report in AEM
(/etc/reports/diskusage.html) reports we are using ~18 GB of data.
However, our datastore has grown to ~170 GB of data. I cannot find any
way to figure out ho...
That resolved the issue, thanks. I found the function to escape illegal
characters from that exact page, but I was not sure why I would need to
to replace characters if they were properly escaped in the first place.
The document doesn't discuss why the replaceAll is there after either. A
little odd. Now, however, the query
contains:jcr:like(fn:lower-case(@jcr:title), '%ma''a%salama%'Will this
be able to match ma'a salama using two single quotes between the a's?
I would agree but I do escape it, using
org.apache.jackrabbit.util.Text.escapeIllegalXpathSearchChars. I have
also tried Text.escapeIllegalJcrChars. Is there no existing function to
escape the query automatically or do I have to write something?
I have a servlet that I use to search the JCR based on a user-provided
query. I log the string that is to be used as the query before running
it. However, I get a parse error when running the query and the error
shows a differently formatted query than the string logged. Am I doing
something wrong or is there a bug in the stack that parses/formats the
query? Below is a servlet that should produce the error and the log
messages I get. The query used is "ma'a salama". req below is the object
I have a completely new installation of AEM 6.2 with a dispatcher,
4.2.0, running on the same server.When I access the application
directly, I can create a new project
I access the application through the dispatcher, using the default
author dispatcher configuration, I cannot create a new project. If I
swap out a new installation of AEM 6.2 with AEM 6.1, I can create a
project in AEM 6.1.In response to the AJAX ...
This does not address the OP's question. How has this been marked as
solved? To re-iterate, the question was: "Please suggest if there is
something wrong in what I am doing or it is a bug in CQ?"I am having the
same issue and it sounds like a bug. If there is a bug and therefore the
only solution, rather than releasing a fix for the bug, is to create our
own servlet to spellcheck, then that would be a clearer response, albeit
a still mostly unhelpful response as this would then require knowledge...