Class InMemoryTransport
- All Implemented Interfaces:
Transport
Connect with a memory:// URL, where the host names the broker instance:
try (AceMq mq = AceMq.connect("memory://orders")) {
mq.declareExchange("orders", "topic");
mq.declareQueue("orders.new");
mq.bind("orders.new", "orders", "order.*");
}
Two connections to the same name share state; a different name is a different broker. A test wanting isolation should use a unique name rather than resetting shared state.
This is a fake, not a simulator, and it is honest about the difference. It implements routing, prefetch and settlement, because those are what most tests actually exercise. It does not implement replication, persistence, delayed delivery or dead-lettering, and does not claim those capabilities, so code that depends on them fails here for the same reason it would fail against a broker that lacks them. The conformance suite will run against both this and real brokers, which is what keeps the two from drifting apart.
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionstatic voidMakes a named broker refuse publishes, the way a real one does under a memory or disk alarm.connect(ConnectionConfig config) Opens a connection.name()static voidreset()Discards every in-memory broker and its contents.scheme()static voidMakes a named broker accept publishes again, releasing every publisher waiting on it.
-
Constructor Details
-
InMemoryTransport
public InMemoryTransport()
-
-
Method Details
-
reset
public static void reset()Discards every in-memory broker and its contents. -
block
Makes a named broker refuse publishes, the way a real one does under a memory or disk alarm.Exists because this failure is worth testing and is otherwise almost impossible to reproduce: publishing to a blocked broker does not fail, it simply never returns, and a service that has not been tested against it will hang in production instead of here.
InMemoryTransport.block("orders", "low on memory"); assertThrows(ConnectionBlockedException.class, () -> publisher.send(order)); InMemoryTransport.unblock("orders");Publishers wait up to
ConnectionConfig.blockedTimeout()before throwing, which is zero by default, so a publish while blocked throws at once. A test that wants a publish to wait forunblocksets a timeout.One deliberate difference from RabbitMQ, worth knowing before writing a test around it: here
isBlocked()becomes true as soon as this is called, whereas RabbitMQ tells a connection it is blocked only when that connection next publishes. Against a real broker the first message into an alarm is already on the wire before anything is known, so it may or may not arrive; here nothing is ever written, andConnectionBlockedException.mayHaveBeenPublished()is alwaysfalse. A test that needs the uncertain case needs a real broker.- Parameters:
brokerName- the host part of thememory://URLreason- what to report as the broker's own explanation, such aslow on memory
-
unblock
Makes a named broker accept publishes again, releasing every publisher waiting on it.- Parameters:
brokerName- the host part of thememory://URL
-
scheme
-
name
-
capabilities
- Specified by:
capabilitiesin interfaceTransport- Returns:
- what brokers reachable through this transport can do
-
connect
Description copied from interface:TransportOpens a connection.- Specified by:
connectin interfaceTransport- Parameters:
config- connection settings;ConnectionConfig.scheme()must matchTransport.scheme()- Returns:
- an open connection
-