I connected a service with the axon server. It just uses the query gateway to request data from QueryHandlers also connected to the axon server … this works as expected.
But the log is polluted with (logs multiple times per second):
Hi Jan,
the message about “registrations subscribed” is actually about the handler methods that are (re)subscribed to AxonServer. It has nothing to do with Subscription Queries.
If you have a component that only sends Queries, but doesn’t handle them, the value will always be 0.
It will also be 0 at first startup when the connection is established, but the handlers still need to be registered. In that case, you will see logging statements that mention the handlers being subscribed.
I am wondering what causes the reconnections all the time, though. How do you configure the connection to AxonServer?
So for a system, that only should use the queryGateway, we disabled the JPAAutoConfiguration, Event- and CommundBus, like this:
@EnableAutoConfiguration(exclude = JpaAutoConfiguration.class)
public class QueryOnlyModeConfiguration implements QueryOnlyMode {
@Bean
@Primary
public SagaStore noopSagaStore() {
return NoOperation.SAGA_STORE;
}
@Bean
@Primary
public CommandBus noopCommandBus() {
return NoOperation.COMMAND_BUS;
}
@Bean
@Primary
public EventStore noopEventBusAndStore() {
return NoOperation.EVENT_STORE;
}
}
(where NoOperation… throws UnsupportedOperationExceptions on all functions).
This works, in the sense that we a) can get the query result via queryGateway (and see the service in the axon server overview) and b) do not get tables (eventStore, sagaStore, tokenStore, …) created in our DB. I guess, we missed some internal requirements and should at least provide an inMemory implementation of … what? Any idea? Where does the QueryChannelImpl check if I am registered/subscribed?
The configuration looks all right, actually. The problem doesn’t seem to be there.
I am wondering where all these log items would come from. Could you perhaps do a stack dump each time the log entry is called (you can make the IDE do that instead of stopping at a breakpoint). I wonder where the requests to connect come from. I would normally just expect one at startup, and no more.
Hi @allardbz . I did not use the IDEA trick yet … but still got an update: I suppressed the log-info, until we got a call because we had 100ks erroneous requests in instana (around 1 every 80 ms) … In the instana report, you can see, that it is a permission problem:
Type RPC Client
Category rpc
Flavor grpc
Host xxx.xy
Remote Port 8124
Procedure/Method io.axoniq.axonserver.grpc.query.QueryService/OpenStream
Error
PERMISSION_DENIED: Invalid token for io.axoniq.axonserver.grpc.query.QueryService/OpenStream
We then did a try and error, the problem stopped, after giving the “I am only interested in using the query gateway” system the access-right: “READ”. Funny thing: this is marked as deprecated in the docs …
for sake of completeness these are the access rights in total now (panning to drop commands/events soon):
I must admit, I am a bit confused … if the READ right seems to be that important, why is it not active by default … and why is it deprecated? and what should we use instead?
I will hand this over to one of my colleagues that can file support requests, just copying this here to round up the discussion an in case it is of value for other users as well …
that last message had the info I needed to find out what was happening. The new connector is quite “pro-active” in setting up a query stream, even if that stream isn’t strictly needed. Unfortunately, it now hits the authorization limitation.
Adding the authorization to HANDLE_QUERIES (and potentially also HANDLE_COMMANDS, for the same reason) should resolve it.
I’ll register a fix for this in the connector’s Github Repository
Naming is a bit confusing … SUBSCRIBE_QUERY_HANDLER seems to mean “I can subscribe (=consume) to a query handler” … but reads like “i have a query handler and am allowed to provide (=register this at the server)” … so the active/passiv role seems to be inverted.
actually, it exactly means what you read from it: ‘you can subscribe a query handler’. The reason that you need to add this role is a limitation of the connector, which actively connects the query stream, even if there is no handlers actually registered.
A fix for this is on its way.