That is the solution we had to go with as well.A feature request was
made to have the runmode configurations for the replication agents match
the runmode configurations for everything else. That ticket is
GRANITE-14360. I was told that the feature wouldn't even be considered
until at least 6.4. If you ask about it then reference that ticket
number and maybe it will get more attention. kyle
There really aren't all that many replication configurations. It's just
multiple sets, like "test", "prod", "staging", "preview", etc. So each
set has its own specific publishers, flush agents, etc. We could just
keep all the configurations separate and know that we need to install
the staging replication agents on staging, and the production
replication agents on production, and so on, It's just much more
convenient when there is only one thing to do and any instance can
behave like any other i...
There seems to be some inconsistency between how run modes are handled
by the replication agent configuration and by other configurations in
AEM.For reference, i am using AEM 6.2,
com.adobe.granite.replication.core:6.0.14At issue here is the fact that
when multiple run modes are appended to a replication agent group, they
are evaluated with an OR operation.Let me give an example. The obvious
run modes that everyone will be familiar with is "author" and
"publisher"; thus, you will typically have ...
Question 1 -The issue I face with manipulating the cost is that now the
index (with its cost manipulated) is sometimes used when its the poorer
choice; it ends up just reversing the problem: queries that were
performing poorly because they weren't using this index now perform
well, but other queries that were performing well, in some cases, now
perform poorly because they ARE using this index where they weren't
using it before.Using native queries seems like it could be the best
solution. Is the...
I will break this question down into two parts because I think they are
probably related.The first relates to what seems like improper index
selection, the second pertains to optimal configuration of indexes. In
AEM most of the queries we do are based on @sling:resourceType,
typically with some second property restriction. In one such case we
make queries for a particular resource type as well as restrictions on a
property called @date. The @date property is of type Date. The queries
include som...
With AEM 6.1 having been released, does anyone know when adobe intends
to update their public maven
repo's?https://repo.adobe.com/nexus/content/groups/public/com/adobe/aem/aem-api/
We use this repo as part of our build, having the new versions available
will make building for AEM 6.1 much easier. We are currently building
for 6.0 (as the dependencies do exist in the public repo) but are not
able to build for 6.1 until the repo is updated. If anyone has some
insight into the timelines, it would b...
I have read your suggestion of only using a 1:1 ratio.Unfortunately, the
1:1 setup, although simpler, has a significant draw back that is an
issue for our use case. We have hundreds of thousands of cache-able
assets. Our caches are cleared quite frequently due to frequent
activations. If we were in a 1:1 setup, this means each dispatcher (and
each cache) only has one render powering it. To fully repopulate the
cache each dispatcher would have to render each cache-able resource at
least once. Wha...
Hello,I have a couple questions about how the Dispatcher performs load
balancing and penalizes unavailable renders.Hopefully someone here will
have useful insight. The documentation for the dispatcher "statistics"
and "unavailablePenalty" are a little ambiguous as to how the load
balancing is actually performed.Here's the documentation:
https://docs.adobe.com/docs/en/dispatcher/disp-config.html#par_168_66_0011Is
there any documentation that details what information is kept in the
"statistics" an...
Also, I have noticed the "Apache Sling Service User Mapper Service
Amendment" factory, which is a much better way of managing these service
users. Tried that, same results. Thanks,kyle
Hello, We have been working with AEM 6.0SP2 and are now moving into AEM
6.1.During our upgrade from CQ 5.6.1 to AEM 6.0SP2 we converted over all
our uses of admin sessions (via resourceResolver.loginAdministrative())
to use service users instead. Here's a snippet of how we get a service
user: try { Map param = new HashMap();
param.put(ResourceResolverFactory.SUBSERVICE, "contentReadService");
this.serviceResourceResolver =
this.resourceResolverFactory.getServiceResourceResolver(param); if
(this....
Typically, any code in which a resource resolver is not tied to a
request, you will need to create/close. So, for example, if you have a
service running in the background; one thats maybe on a schedule.There's
no request whose resource-resolver you can re-use, so you create one
manually directly from the factory for use by this service.You will be
responsible for closing this resource resolver/session.
I see the exact same issue com.day.cq
cq-quickstart 6.1.0
provided apis I've
tried deleting the repository, fetching other dependencies and plugins
from maven central instead of adobe repos (where possible), updating all
dependencies and plugins to the latest supported in AEM 6.1, updating
maven to latest stable versions, updating java to latest stable
versions, all to no avail. Error is as follows: [ERROR] Failed to
execute goal org.apache.felix:maven-scr-plugin:1.21.0:scr
(generate-scr-scrdes...
