When stopping the Fractal components associated to the JBI artefacts, the JBI artefacts are stopped without persisting the state STOPPED, but endpoints are deactivated.
As these Fractal components are stopped before the router, it exists a little moment where we can get the error mentioned in the issue summary.
It has no sens to stop JBI artefacts and their associated Fractal components:
- the external listeners of JBI components must always accept incoming request during container attachment/detachment
- just incoming message exchanges at NMR level must be blocked during the attachment/detachment process, for example at router entry point
- to migrate registry data from a registry to the other one, it is sufficient to make the migration when the router is stopped. That's why
PETALSESBCONT-358 has been reopened.
So, the right process to block service invocations is something like:
- pause the router:
- to wait the end of pending exchanges. We wait that pending exchanges are ended under a given time. When this time expires, the process continues and pending exchanges will probably fail later.
- to interrupt all delivery channels waiting message exchanges. Delivery channels will retry to wait to receive new message exchanges until the router is resumed,
- caution, the send of synchronous invocations is blocked at transporter level. It should be better to moved that at router level (
PETALSESBCONT-368).
- stop the Fractal component 'Router'. All incoming calls to the router methods will be blocked at Fractal framework level,
- migrate registry data,
- start the Fractal component 'Router',
- resumed the router.
Bug
Resolved
Major
When stopping the Fractal components associated to the JBI artefacts, the JBI artefacts are stopped without persisting the state STOPPED, but endpoints are deactivated.
As these Fractal components are stopped before the router, it exists a little moment where we can get the error mentioned in the issue summary.
It has no sens to stop JBI artefacts and their associated Fractal components:
PETALSESBCONT-358has been reopened.So, the right process to block service invocations is something like:
PETALSESBCONT-368).- the external listeners of JBI components must always accept incoming request during container attachment/detachment
- just incoming message exchanges at NMR level must be blocked during the attachment/detachment process, for example at router entry point
- to migrate registry data from a registry to the other one, it is sufficient to make the migration when the router is stopped. That's why
So, the right process to block service invocations is something like:PETALSESBCONT-358has been reopened.PETALSESBCONT-368).