axonframework / extension-multitenancy Goto Github PK

Expected behaviour

Heartbeat should not depend on default context, as there might not be default context at all, it should connect to _admin context instead.

Actual behaviour

Heathbeat is connected to default context.

Basic information

The javax.annotation.PostConstruct annotation is used in two places. This will not work with Jakarta/Spring boot 3.

Steps to reproduce

Use the extension in a Spring Boot 3 project. Since the AxonServerTenantProvider will never start, it will never find any context/tenant.

Expected behaviour

It works properly, also with Spring Boot 3 / Jakarta.
Alternatively the AF Lifecycle interface can be used to start.

Actual behaviour

It doesn't start the AxonServerTenantProvider or the CloudTenantProvider.

Basic information

• Axon Framework version: 4.9.2
• JDK version: 17
• Multi-Tenancy Extension version: 4.9.2
• Complete executable reproducer if available (e.g. GitHub Repo): -

Steps to reproduce

1. start a app using the Multi-Tenancy Extension connected to a AxonServer
2. register MultiTenantAwareComponent against the TenantProvider (auto-configured to AxonServerTenantProvider)
3. cancel that registration

Expected behaviour

All the individual tenant registration from the concerned MultiTenantAwareComponent are cancelled.
No other side-effects:

• registrations for other MultiTenantAwareComponent are maintained
• connection to Axon Server is maintained for all tenants

Actual behaviour

Registration for all MultiTenantAwareComponent are cancelled on all tenants, not just the concerned MultiTenantAwareComponent.
Connection for all tenants are closed on Axon Server.

See: https://github.com/AxonFramework/extension-multitenancy/blob/main/multitenancy-spring-boot-autoconfigure/src/main/java/org/axonframework/extensions/multitenancy/autoconfig/AxonServerTenantProvider.java#L204-L212

Feature Description

Add support for a multi-tenancy aware DeadlineManager, in a similar fashion as other Axon Framework components support multi-tenancy.

Feature Description

Add support for a multi-tenancy aware EventScheduler, in a similar fashion as other Axon Framework components support multi-tenancy.

Feature Description

This multi-tenancy extension uses a customized EventProcessorControlService to enable event processor operation through the Axon Server dashboard.
With Axon Framework 4.8.0, this service includes setting the (auto) load balancing strategy from the application.properties file.

As the EventProcessorControlService#start method is overridden by the MultiTenantEventProcessorControlService, we lose this capability entirely.

Current Behaviour

The multi-tenancy extension does not support load-balancing strategy configuration through a properties file.

Wanted Behaviour

The multi-tenancy extension supports load-balancing strategy configuration through a properties file.

Possible Workarounds

Adding a custom MultiTenantEventProcessorControlService that enables this behavior.

Same local segment command bus is reused between tenant axon server command segments. And then if I add handler interceptor to the multitenant bus, it applies on each tenant command bus when it is started and each tenant bus applies it on a single instance of the local segment bus. As a result if you have N tenants, your local segment bus will have N same handler interceptors.

Wanted behaviour:
Each tenant segment should have its own simple command bus. In our case tenant segment has its own axon server command bus, but axon server command bus uses shared command bus, that causes this issue.

Basic information

• Axon Framework version: not relevant
• JDK version: not relevant
• Multi-Tenancy Extension version: not relevant
• Complete executable reproducer if available (e.g. GitHub Repo): not relevant

Steps to reproduce

Create a tennent, remove and create a tennent with the same name. While the projections and events are removed, event processing will be 'stuck' where it was left since the tokens aren't removed.

Expected behaviour

Tokens are removed in the stopAndRemoveTenant method of the MultiTenantEventProcessor

Actual behaviour

Event processors are shut down, but the related tokens aren't deleted.

Feature Description

Add possibly to set custom message source per tenant.
For example if user wants to listen events from tenant specific Kafka topic they would need this functionality.

Current Behaviour

It is not possible to set message source other then default multi tenant event store

Wanted Behaviour

If a user provides a bean, it can be used to override and set custom message source for given tenant.

Check if all public methods have Javadoc and in the Javadoc is correct

Enhancement Description

Check and design better usability in cases where clients have multiple bounded context.
In that case, the tenant != context, as the tenant should belong to any of these bounded contexts.

Note that this enhancement focuses on the multi-context support from Axon Server, which you can use to define distinct bounded contexts.
Combining that behavior with a desire for multi-tenancy requires additional work in the Multitenancy Extension.

Current Behaviour

Each context is considered a separate tenant, mapped 1:1.

Basic information

• Axon Framework version: N/A
• JDK version: N/A
• Multi-Tenancy Extension version: Master as of commit: 585f9c9
• Complete executable reproducer if available (e.g. GitHub Repo): N/A

Steps to reproduce

1. Navigate to: https://github.com/AxonFramework/extension-multitenancy
2. Scroll down through readme
3. Click the "reference guide link"

Expected behaviour

Browser navigates to reference guide

Actual behaviour

Browser navigates to page displaying "page not found" error.

If a service is already running before Axon Server is started, the context is not propagated to the service until that service is restarted.
In other words, when a user of this extension connects during the "reconnect" phase and then a new context is created, the service is required to be restarted.

Steps to reproduce and problem

The following message from a user of the extension makes the predicament clear:

Hi,
We encounter a strange behaviour with the services and contexts: It looks like, that if a service is already running before the axon server is started, so the connection happens during "reconnect", and then a new context is created, the context is not propagated to the service, until that service is restarted again.
Is this Problem already known? is there a configuration option etc, that solves this?
(We are using the tenants for multi tenancy => new contexts will dynamically be created, and therefore it is important, that all services notice this new context.

For the context registration/detection we are using:

public TenantConnectPredicate tenantFilterPredicate() {
    return context -> context.tenantId().startsWith("organization-");
}

Expected behaviour

The Multitenancy Extension should be resilient and reconnect if context updates break the channel's connection.

Actual behaviour

The Multitenancy extension may lose the connection from the context updates channel.
Since it is unable to reconnect, future updates never occur.

Enhancement Description

Any extra and/or Axon Server-specific properties, such as the replication group, should be part of meta data instead of the API.

Current Behaviour

The replication group is exposed as part of TenantDescriptor.

Feature Description

A dead-letter queue implementation dedicated to multi-tenant delegation will allow users constructing a multi-tenant application to utilize the DLQ support with ease.

Current Behaviour

There is no MultiTenantSequencedDeadLetterQueue implementation at all.

Wanted Behaviour

Constructing a MultiTenantSequencedDeadLetterQueue implementation delegating to SequencedDeadLetterQueue instances per tenant.

Possible Workarounds