Resources["ContentLoaderFunctions"].Delete() produces a "Read timed out" error

[jensc]

Hello community,

While doing tests on creating/deleting projects, I am trying to use the following function:

let url = '.../Thingworx/' + entity.type + "s/" + entity.name
var params = {
  headers: {
    "appKey": appKey,
    "Content-type": "application/json",
    "Accept": "application/json"
  } /* JSON */ ,
  url: url /* STRING */
};
Resources["ContentLoaderFunctions"].Delete(params)

For some reason though it is SUPER slow (and seems to be causing me to not be able to delete entities manually in the composer at the same time).

I do get the following error in my ScriptLog:

JavaException: java.net.SocketTimeoutException: Read timed out

Eventually though, the entities are deleted and I can see this in the "ConfigurationLog":

Which confirms that the "Administrator" (user used for the AppKey during tests) had deleted the entities.

But what could be the reason for the time out issue?

Thanks,

Jens C.

[nmilleson]

@jensc ,

If you make the same call in Insomnia or PostMan, do you see the same delay?  Additionally, is there a reason why you're using the ContentLoader functions to delete entities and not the built-in services?

-Nick

[jensc]

Hello @nmilleson,

When trying from Insomnia (and running the service from the composer), nothing really happens. I get a response 200 back in insomnia, but the entity still remains. Perhaps my request is wrong?

Body:

Header:

The reason why I am using the contentloader for deleting this entity is because there is no entityservice to delete mashups (and some other entity types).

If you know of any other services that can actually delete stuff like mashups, menus etc, then I'd be happy to give it a shot though!

Thanks,

Jens C

[nmutter]

(you are doing a POST request in your screenshote instead of a DELETE request)

edit: ah I just noticed you call the contenloaderfunction service. so POST would be ok. But why not bypass the ContenLoaderFunction and call DELETE on 

'.../Thingworx/' + entity.type + "s/" + entity.name

I think this was the idea if this even works

[nmilleson]

@jensc 

Could you try running the DELETE operation from Insomnia? (rather than calling your service)

The one mentioned here (which looks to be the same as the one you're calling with ContentLoader functions)

https://www.ptc.com/en/support/article/CS284110

[jensc]

Hello @nmilleson, @nmutter,

The DELETE request does indeed work from Insomnia.

However, I do not know how to make a DELETE request from Thingworx other than using that contentloader function.

I thought that was how you did it?

Is there some other way?

Thanks,

Jens C

[Rocko]

On the slowness and timeout, there might be still concurring locks on those objects. You could test if it is still slow in deletion after e.g. restarting the server.

[nmutter]

ContentLoaderFunction is correct. The idea of  @nmilleson was just to try if the requests already runs into the issues when called via rest api directly. Which you say is not the case. So the call itself is not the issue. Ruling out that the DELETE itself causes the issue already.

[jensc]

Hello @nmutter,

When trying the ContentLoaderFunction from Insomnia, I am not able to use it at all, I get a response 200 back, but it doesn't delete anything.

I tested to run it both as POST and PUT, neither worked.

I can't run it as a DELETE as then Thingworx interprets it like I am trying to delete the ContentLoaderFunction object.

What worked was running a "normal" delete on the test mashup object.

Trying to restart the server as @Rocko suggested will likely be my next test.

I'll write once I've had the server restarted and done another test.

Thanks,

Jens C.

[nmilleson]

@jensc ,

Out of curiosity, in your ThingWorx service, are you using a relative or absolute URL as your path?  Does it make a difference in execution time?  Additionally, do the tomcat localhost access logs show anything strange when running that service?

- Nick

[nmilleson]

@jensc ,

One other thing I'd try is making that service async and firing an event at the end of it.  Then write a subscription to that event and maybe do some logging to see if it still has that long lag.

- Nick

[jensc]

Hello @nmilleson,

Response to first post:

I am using an absolute URL path in all tests. I have not tested with a relative path, so not sure if it would make it better...

I haven't had time to ask my infra team for a restart. But I'll try to do it tomorrow and I'll also make sure that they check the logs when I run the service to see if they can see something.

They did send me the following from the configs though:

<Connector port="xx" protocol="HTTP/1.1"
               connectionTimeout="90000"
               redirectPort="xxxx" />
                   
  
<Connector port="xxxx" protocol="org.apache.coyote.http11.Http11NioProtocol"
           SSLEnabled="true" maxThreads="200" scheme="https" secure="true"
           maxHttpHeaderSize="8192" connectionTimeout="90000" minSpareThreads="25"

But I don't think this is the same timeout as I am facing from the script.

Response to second post:

I'll give it a shot and see if it could provide any information.

I'll post again once we have done some more tests.

Thanks,

Jens C.