›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Synchronously Waiting for Reply

AaronThorpAaronThorp
in SRP Engine Server
We are utilising the SRP engine to fire in requests from our external message queue to mobile devices and then back on the queue on the way out and we are now working on dashboards that poll for data at intervals as well.

Happily firing fire-and-forget messages to the SRP server for this to work, and I have played around with the mode that the DirectConnect control async mode (the 0x06 packet) that returns the results after execution as I would like to be able to get a feed back of the result synchronously.

Now while I have got it to successfully work and send back the results there are a couple of niggling data structure/flow questions that I am not sure about in terms of the communications method that you may be able to shed some light on for me, the issue I am having is that if multiple requests return parallel from the multiple engines, for some reason the data is getting intertwined together in the results feed...(e.g. I packed it into the OECGI.php file and so far seems quite performant) but if you request a few pages at the same time it mixes the results together like it is all on the one channel.

Is there some sort of data-flow spec that you could possibly share with me as to the correct way that the server returns results from these requests in some sort of separable channel flow for the 0x06 command to seperate the results correctly?

Thanks.

Comments

  • KevinFournierKevinFournier
    Do you have multiple DirectConnect controls making requests? If so, then I think I know the problem. DirectConnect generates a numeric ID attached to the request, so if you have two DirectConnect controls, they could be sending the same IDs simultaneously. The solution would be for me to add a parameter so you could generate IDs yourself.
  • AaronThorpAaronThorp
    After some more testing, namely testing firing 30 requests to the server at once returning 50000 of the same character sent as the parameter and then testing for anything but that character in the responses, I haven't yet found any overlaps so far, I am not using directconnect control but for those that may be, that could be a good parameter to have available, I am incrementing the ID tho each time and filtering the return buffer only to ones that match the ID on the end of the packet as a "Just in case".

    So continued testing, I am leaning towards it actually coming down to calling the same program/report with different parameters at the same time might actually be mixing the SYSLISTS that the RList statements are generating together and messing up all the keys for the readnext's between the multiple OE servers processing the calls...? would that be a possibility? I might have to randomise the workstation ID when engines are opened on the SERVER to prevent some overlaps maybe?

  • AaronThorpAaronThorp
    you can close this, turns out it was some one else's coding style with this report writing to a temporary file causing my hair pulling issues, all sorted. thanks.
Sign In or Register to comment.