It looks like the problem is related to the 2nd GET query and the failure to lookup with the session created on the previous [successful] login/authentication POST (using the generated JESSSIONID cookie / lisa.vse.sesion.key)>
(I've attached VS_inventory_device_good|bad.log files with examples of both failure and success cases.)
In most cases the GET /dataservice/device is working ...
2019-02-01 14:38:50,446Z (09:38)[inventory_device [VS_inventory_device_Run]/1] INFO - New session New session created for key: S7AGHN18e4GJ2IhAtXX9x1aGc1Ng_22WALf0MGrn&188062c6-b0e9-795b-f23e-1383963326ad
...
2019-02-01 14:38:50,542Z (09:38)[inventory_device [VS_inventory_device_Run]/1] DEBUG - Inbound Request {"id":0,"operation":"GET /dataservice/device","arguments":{}}
2019-02-01 14:38:50,542Z (09:38)[inventory_device [VS_inventory_device_Run]/1] INFO - Inbound Request {"id":0,"operation":"GET /dataservice/device/","arguments":{}}
2019-02-01 14:38:50,542Z (09:38)[inventory_device [VS_inventory_device_Run]/1] INFO - Existing session Attached to existing session for key: S7AGHN18e4GJ2IhAtXX9x1aGc1Ng_22WALf0MGrn&188062c6-b0e9-795b-f23e-1383963326ad
...
... and [intermittently] it fails with ...
2019-02-01 14:39:06,570Z (09:39)[inventory_device [VS_inventory_device_Run]/1] INFO - New session New session created for key: V1NHTZ14ldJT1FsFeXF6l1fKw5Cz_39UVEp6CEca;170120a7-b302-3302-8035-7b79375ec167
...
2019-02-01 14:39:06,657Z (09:39)[inventory_device [VS_inventory_device_Run]/1] DEBUG - Inbound Request {"id":0,"operation":"GET /dataservice/device","arguments":{}}
2019-02-01 14:39:06,658Z (09:39)[inventory_device [VS_inventory_device_Run]/1] INFO - Inbound Request {"id":0,"operation":"GET /dataservice/device/","arguments":{}}
2019-02-01 14:39:06,658Z (09:39)[inventory_device [VS_inventory_device_Run]/1] DEBUG - Operation match failure source: 'POST /j_security_check/', incoming: 'GET /dataservice/device/'
2019-02-01 14:39:06,658Z (09:39)[inventory_device [VS_inventory_device_Run]/1] INFO - No Session ID No session identified
2019-02-01 14:39:06,658Z (09:39)[inventory_device [VS_inventory_device_Run]/1] INFO - No Stateless Match Could not match a stateless transaction
2019-02-01 14:39:06,659Z (09:39)[inventory_device [VS_inventory_device_Run]/1] WARN - No Match Request <?xml version="1.0" ?>
<request operation="GET /dataservice/device/" matchTolerance="EXACT">
<attributes>
<parameter name="HTTP-Segment-Attr-0">dataservice</parameter>
<parameter name="HTTP-Segment-Attr-1">device</parameter>
</attributes>
<metaData>
<parameter name="HTTP-Method">GET</parameter>
<parameter name="HTTP-URI">/dataservice/device</parameter>
<parameter name="HTTP-Version">1.1</parameter>
<parameter name="Accept-Encoding">identity</parameter>
<parameter name="Host">servicesim.ca.com:8446</parameter>
<parameter name="Cookie">JSESSIONID=V1NHTZ14ldJT1FsFeXF6l1fKw5Cz_39UVEp6CEca;170120a7-b302-3302-8035-7b79375ec167; path=/; secure; HttpOnly</parameter>
<parameter name="Connection">close</parameter>
<parameter name="User-Agent">Python-urllib/2.7</parameter>
<parameter name="lisa.vse.session.key">V1NHTZ14ldJT1FsFeXF6l1fKw5Cz_39UVEp6CEca</parameter>
<parameter name="lisa.vse.request.client.id">138.42.248.62:41856</parameter>
<parameter name="matchedRule">GET /dataservice/device/</parameter>
</metaData>
</request>
From the incoming GET request, I see the Cookie parameter and it seems to align with the generated key in the original POST.
Still not clear why it works most of the time. Is there a subtle issue here or am I missing some additional configuration to relate the Cookie/JSESSION and lisa.vse.sesion.key?
Thanks for the responses.
-Fred