# Messaging (ActiveMQ / RocketMQ)

Not every integration in xly is a synchronous HTTP call. The framework
runs two message brokers, each with a different role:

| Broker | Used for | Producer | Consumer |
|---|---|---|---|
| **ActiveMQ / JMS** | Cache invalidation, in-cluster fan-out events. The metadata-change pipeline ([cache invalidation](../reference/maintainer/cache-invalidation.md)) rides on this. | `xlyErpJmsProductor` | `xlyErpJmsConsumer` |
| **RocketMQ** | Other integration flows where the ActiveMQ assumptions don't fit. | `RocketMQServiceImpl` (in `xlyBusinessService`) | (varies — service-specific) |

This page is a pointer rather than a deep dive — exact queue names and
payloads are documented at the consumer-thread level in
`xlyErpJmsConsumer/src/main/java/com/xly/xlyerpjmsconsumer/`.

## ActiveMQ / JMS — the cache-invalidation channel

Producer-side queue declarations live in
`xlyErpJmsProductor/src/main/java/com/xly/xlyerpjmsproductor/config/P2pQueue.java`.
Notable destinations the framework uses today (read the file for the
full list):

| Constant | Purpose |
|---|---|
| `ERP_JMS_ACTIVEMQ_CHANGE_GDS_MODULE` | "Module metadata changed" — triggers `ConsumerChangeGdsModuleThread` to bust the relevant Redis caches across nodes. See [Cache invalidation on metadata change](../reference/maintainer/cache-invalidation.md). |
| `ERP_JMS_ACTIVEMQ_CHANGE_ELE_CUSTOMER` | Customer-master change fan-out. |
| `ERP_JMS_ACTIVEMQ_CHANGE_ELE_EMPLOYEE` | Employee-master change fan-out. |
| `ERP_JMS_ACTIVEMQ_CHANGE_ELE_MACHINE` | Shop-floor machine-master change fan-out. |
| `ERP_JMS_ACTIVEMQ_UPD_SALE_ORDER`, `ERP_JMS_ACTIVEMQ_UPD_WORK_ORDER`, `ERP_JMS_ACTIVEMQ_UPD_PRODUCTION_REPORT` | "Document was updated" notifications consumed by background workers (totals recalculation, downstream invalidations). |
| `ERP_JMS_ACTIVEMQ_DEL_SALE_ORDER`, `ERP_JMS_ACTIVEMQ_DEL_WORK_ORDER`, `ERP_JMS_ACTIVEMQ_DEL_PRODUCTION_REPORT` | Document-delete notifications. |

Each destination has a corresponding `Consumer*Thread` class under
`xlyErpJmsConsumer/.../thread/` that handles the message asynchronously.

## RocketMQ — other flows

`RocketMQServiceImpl` and its companion `RocketMQService` interface
sit in `xlyBusinessService/src/main/java/com/xly/service/`. They cover
non-cache-invalidation flows (for example, `MQCompensateServiceImpl`
handles compensation/retry semantics that ActiveMQ's destinations don't
express well). RocketMQ topics are configured per environment.

## Manual cache-invalidation poke

If a metadata change happens via raw SQL (no JMS event), the cache
across nodes will not bust automatically. The supported override is
`BusinessCleanRedisDataImpl` in `xlyBusinessService/.../service/impl/` —
it can publish an invalidation event directly. See
[cache invalidation on metadata change](../reference/maintainer/cache-invalidation.md)
for the broader troubleshooting path.

## What this is *not*

- **Not a public integration channel.** External integrators do not
  publish or subscribe to these brokers. They are *internal* fan-out
  for the cluster.
- **Not the only way to invalidate caches.** The HTTP write paths in
  `xlyEntry` already publish JMS events when they should; the manual
  poke is for edge cases.