A handy way to find the process is to check your lock table.  These processes will typically take out a lock based on the Task ID.   This can be used to find the process, examine it and kill it if required.

It's also possible in some cases for the process to die and not update the task, and this can account for no processes matching this criteria

Based on this error: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure , you probably want to enable SSLv3 on your SSLConfig. It's showing as disabled in your screenshot

This type of request is handled via your contract arrangements, so the best route is to engage your support service who will be happy to get you the assistance you require

Hi Ramil

This sort of request is handled by your account with Trakcare support.   I would recommend you engage with your local support team using iService to proceed with this requirement

If only seeing new data suits your use case, then you are probably ok with this approach.   You may wish to look at %ValidateIndices() which I believe is present in Cache2018.   This will allow an online check of the index state and can either report on mismatches, or be set to autorepair.  It is MUCH slower than a %BuildIndices, but does not require a full freeze for safety

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Hi Token

I think this might be case senstivity, try using %request.Content and see if that works better?

Regards

Chris

Great new feature!   Even more glad to hear there is no work required to use it after we upgrade

HI Ben, 


I believe this is implemented specifically on each mail server and client, so there is no standard for it: See https://www.chilkatsoft.com/p/p_471.asp for details

You can set these headers, but there's no guarantee the client or receiving server will take note of them

HTH

Chris

Hi Julius

Thanks for your comments, and you are correct in assessing this is for a specific use case (I'm migrating data between 2 structures and want to make sure the exported JSON is EXACTLY the same).

For the first point, I really only care that all values in the source are also in the target.   If I wanted to be thorough, I woudl run the compare in both directions, but since I'm expecting that the target will contain additional properties, I only need a 1 way compare)

For the second point, I actually define the ordering of exporting of arrays explicitly, so I would expect a like for like compare.   For other cases, additional logic would need to be added, as you pointed out

For the last point,  this should return a mismatch, which is good enough for my use case, but again, might not be ideal for other use cases