Alcatel Unleashed

I'm testing the routing again in release 29.

I'm starting out with this state
Then I'm sending a DELETE http://srvroxe01.nxodev.intra/api/rest/ ... me=oxe7890. I get a 204 response back, so Im assuming all is well.

However, if I make a subsequent GET http://srvroxe01.nxodev.intra/api/rest/ ... me=oxe7890, I'm seeing the exact same values returned again. I would expect the overflow route to be cleared

I would expect a subsequent get of the routing state to not have an overflow route anymore, yet

Cannot reproduce the pb. (doing same operations)

The cause may be that management PBX events are no longer received by O2G:
Please:
- if possible check OXE Subscriber/Dynamic_State_User to check if the delete command really runs
and provide logs:
- put cache module in debug (from .../api/Log4jAdmin page)
- and provide: /logs/tomcat/chameleon/cache.log or zip all .log files

After, O2G service tomcatd restart, does the pb persist ?
If yes, is it possible to check in OXE the number of Events_Routing_Discriminator IP addresses? (there is a max number, which depends on OXE version)

merci

Here you go with the traces.

I wrote a little test case so you can see the timestamps

10:02:41 User oxe7890 has one overflow route of type NO_ANSWER, destination Destination type NUMBER acceptable device 1004 selected continuing test
10:02:45 cleared overflow route of oxe7890, trying to extract state again: OK
10:02:45 Server srvroxe01.nxodev.intra is now reachable
10:02:50 User oxe7890 still has an overflow route of type NO_ANSWER destination Destination type NUMBER acceptable device 1004 selected . Test failed

I already verified that nothing is being done directly through OXE last Friday.

I'll try rebooting now and run the test again.

@edit: rebooted, ran the test again. Same result

ok: the problem appears in multidevice user configuration and is located at OXE level: if the request contains overflow to "none" but includes the associated number with unchanged value, the overflow is set to no_answer default value.

(the same operation on mono device user is working)

The problem should be fixed at OXE level.

But waiting for that, we have 2 bypass solutions :

1) at OG level, remove the associated number parameter when the operation is overflow cancel => need a new O2G version
2) the application can make an overflow with associated number=itself: it will produce the same result than a DELETE
POST .../routing/overflow?loginName=oxe70123
{
"overflowRoutes": [ {
"overflowType": "NO_ANSWER", <-- use this value only
"destinations": [ {
"type": "NUMBER",
"number": "70123" <-- the number of the user itself
} ]
} ]
}

That works.. unfortunately, the next bug is right behind it..