Skip to content

Testing Connector replacing in-memory connector - #3506

Open
ozangunalp wants to merge 2 commits into
smallrye:mainfrom
ozangunalp:testing_connector
Open

Testing Connector replacing in-memory connector#3506
ozangunalp wants to merge 2 commits into
smallrye:mainfrom
ozangunalp:testing_connector

Conversation

@ozangunalp

Copy link
Copy Markdown
Collaborator
  • Rename in-memory connector to testing connector: relocation in place for existing in-memory module to work. InMemoryConnector and existing API are deprecated but functional.
  • TestingConnector keeps the overall behaviour but renames method names for easier API ergonomics:
    • incoming returns TestIncoming channel that allows delivering in messages to the application channel.
    • outgoing returns TestOutgoing channel that allows verifying sent messages.
  • EmitterFactories now receive channel config so they can decide whether to create a testing no-op emitter for emitter types such as Request/Reply or Transaction etc.

Addresses #3104

Add connector-aware EmitterFactory API so connector-specific emitters
(KafkaTransactions, PulsarTransactions, KafkaRequestReply, AmqpRequestReply,
RabbitMQRequestReply) work with non-native connectors like the test connector.

When a channel's connector differs from what the emitter factory expects,
the framework calls createFallbackEmitter() to produce a no-op implementation
that sends messages through the standard emitter path without requiring
a real broker.

Also rename the in-memory connector to TestingConnector (smallrye-testing) with
new TestIncoming/TestOutgoing interfaces using deliver()/sent() methods.
Old InMemoryConnector/InMemorySource/InMemorySink classes are deprecated
but remain fully functional for backward compatibility.
…essaging-testing

The old artifact ID is preserved as a relocation POM that pulls in the
new artifact transitively. Existing consumers will get a Maven warning
and continue to work.
try {
NoOpTransactionalEmitter emitter = new NoOpTransactionalEmitter();
return work.apply(emitter)
.call(() -> emitter.waitOnSends())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Kafka no-op (NoOpKafkaTransactionsImpl) checks emitter.isMarkedForAbort() after the work function completes and throws TransactionAbortedException if set. The Pulsar variant does nothing.

// In Kafka
return work.apply(emitter)
    .call(() -> emitter.waitOnSends())
    .chain(result -> {
        if (emitter.isMarkedForAbort()) {
            return Uni.createFrom().failure(new TransactionAbortedException());
        }
        return Uni.createFrom().item(result);
    })
    .eventually(activeTransactions::decrementAndGet);

// In Pulsar (missing abort check)
return work.apply(emitter)
    .call(() -> emitter.waitOnSends())
    .eventually(activeTransactions::decrementAndGet);  // <-- no abort check

Should it be symmetric?

public <M extends Message<? extends T>> void send(TransactionalEmitter<?> emitter, M msg) {
sendMessage(msg).subscribe().with(unused -> {
}, throwable -> {
});

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe at least a warning?

*/
@Deprecated(forRemoval = true)
public static void clear() {
List<String> list = System.getProperties().entrySet().stream()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Deprecated(forRemoval = true)
public static void clear() {
    TestingConnector.clear();
}

final Flow.Publisher<? extends Message<T>> source;
private final String name;
private final Context context;
private boolean runOnVertxContext;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should it be volatile?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants