If I understand you correctly, you are doing this access as part of a
SlingModel, meaning that your browser does not a request to /etc/. Is
that correct?Because in that case the dispatcher itself is not involved,
because it just receives a HTML response from publish, and the
dispatcher does not know how the publish internally assembled this
response. In that case your problem is different.
To add some aspects on top: The number of items in the replication queue
is not limited, but of course a large number of replication items in the
queue can have an impact on the responsiveness of the authoring UI
(especially on ClassicUI). Also some other aspects will get slower when
the number of items in the queue is just growing.
I wrote part 4 of my "Integration testing with AEM" series, which covers
how easy it can be to validate your dispatcher setting, for example to
check if the initial redirect is working correctly or if the "infinity"
selector is correctly blocked for JSON requests.
https://cqdump.wordpress.com/2021/01/18/writing-integration-tests-for-aem-part-4/
AEM can do that for you: * Create a group on Okta side, which members
should be able to perform this action* Make sure that this group is
synchronized to AEM (login with a user of that group and check that this
group is synchronized to AEM).* Adjust the permissions assigned to this
group in the way you require. This is straight forward way and doesn't
require any coding.
Hi,I would not move stuff to /apps, because that's normally read-only
and not writeable (except for administrator group by default); in AEM as
a Cloud Service it's not writable at all during runtime.If your
configuration is supposed to be changed during runtime I would store it
either in /content or /conf.
That's a strange behavior, because restarting a bundle should not change
any internal state.The only thing I could imagine for this is that a
service is stopped from that bundle during these days. Before you
restart that bundle, can you check the list of services exported from
that bundle and their state and compare it the same after you have
restarted the bundle?
This is a conflict which the system cannot handle itself. But in many
cases it is also a sign of a bad application design.I see 2 options: 1)
Make a reference optional and deal with this optionality in the
application code. Just make sure that the optional reference is greedy,
so it's getting satisfied as soon as the reference target is available.
2) Redesign your services so you don't have this circular dependency
anymore. Most likely the creation of a third service C makes sense,
which both A ...
Hi 1780 TIMER_END{31,ServletResolution}
URI=/content/wknd-spa-angular/us/en/home/jcr:content/root/responsivegrid/custom_component.model.json
handled by Servlet=org.apache.sling.servlets.get.DefaultGetServlet 2443
LOG Using org.apache.sling.servlets.get.impl.helpers.JsonRenderer to
render for extension=json for me that's the problem, because it should
not resolve to the DefaultGetServlet, but to a servlet of the
SlingModels package.At which step in the tutorial does this problem
occurr?
You can use localhost:4502/system/console/jcrresolver to check the
resolution of these URLS. Unfortunately I don't see from the screenshot
what path these clientlib requests are using.
Instead of the how, the question is rather if you want to maintain user
information on publish at all? The straight-forward way of using JCR
users very likely doesn't scale in terms of performance, and also you
need think about how you synchronize changes amongst all publish
instances.
Technically both the filevault-package-maven-plugin and the
content-package-maven-plugin can largely the same work, but the
Jackrabbit plugin is currently maintained and developed, but the
development of the content-package-maven-plugin got stalled for quite
some time now. I would recommend to stick to the
filevault-package-maven-plugin, because only that is supported on AEM
cloud service. And more or less the same with the bnd-maven-plugin. The
maven-bundle-plugin was only a shell around bnd fo...
Hi, ObservationListeners run asynchronous to the operation which
performs the save. Which means that there is no guarantee at all
regarding timing. So using the JCR Observation Handler to trigger
another asynchronous operation (sling Job, or a custom implementation)
does not make the situation worse. 🙂
I started with a small series of blog posts how to write integration
tests for AEM, which you can both ran stand alone and which are also
picked up by Cloud Manager. Even a few basic tests can save you a ton of
manual tests. See
https://cqdump.wordpress.com/integration-tests-with-aem/ for an overview
and the links to the individual posts.If you have questions to it,
please raise it here in the AEM Forums and ping me directly (via
"@joerghoh" ), so I can react on it. cheers,Jörg
if you rename the quickstart.jar to aem-65-p4503, the runmode "publish"
is not deduced from the name of the jar, but only the port, so
technically you have an author running on port 4503. But anyway, the
default passwords still should work. You can either try to analyze the
issue or you can just start over.
Opening a ResourceResolver is normally opening a JCR session. Which
comes with some overhead.Some time back I profiled a publish instance in
load tests and found that eliminating a single filter, which opened and
closed a JCR session (and doing some work in between) increased the
number of requests my publish was able to handle by ~ 5%.So if you do
that lots of times during the rendering of a page, it will negatively
impact the performance of the page rendering. Jörg
As others already stated, it's hard to give any number for that, but in
reality I haven't seen servers which are maxed out just by running the
dispatcher. Normally the AEM publishs are maxed out much earlier 🙂And
regarding your second question: If you have a single dispatcher, it is
one single point of failure. Not necessarily the only one, because in
that case it's likely that you have a single publish instance, too. Jörg
From what I know this is not possible. You would need to use multiple
threads to handle the events of an event iterator in a parallel way. But
the code on that low level is not thread-safe. But to be honest I have
never tried that, and I am very sure, that you would be the first one to
try that.The rule of thumb for JCR Observation Listener is to be as fast
as possible. If you processing is expected to take longer, you should
offload from this thread (e.g. feeding a queue where a dedicated
threa...
Hi, by default the dispatcher does not cache any files, for which the
request has certain "authentication" headers. That is an "authorization"
header or a cookie "authorization" resp "login-token". If any of these
are present, the dispatcher won't cache the files, unless you explicitly
configure it to do so.
The ratio is calculated as (100 * req_hits / req_total) with req_hits =
# files delivered from cachereq_total = the total number of requests
handled by the dispatcher from this point of view the cache-hit ratio is
the same if requests are blocked on dispatcher (not httpd!) or forwarded
to publish. So the number is nice, but it's hard to draw meaningful
conclusions from it.
When you use CUGs and want to cache protected content, you should use
"Permission Sensitive Caching", see the documentation at
https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/permissions-cache.html?lang=en#configuring
I don't think that this feature is really required, because you can
always do a force-push from your own git to the CloudManager git. That
means that any push directly into the CM git by a developer will be
overwritten.
To put it in other words: It is not supported on any other java than
Oracle Java. But you might be able to develop locally on it using
OpenJDK. (I am not aware of any incompatibilities which are relevant for
AEM custom application development.)
How did you bootstrap the archetype? I don't have a maven module
"mysite.dispatcher.ams" (it's the "ams" extension which I wonder about)
in my bootstrapped archetype (default values).
