Service "pub.file:getFile" throw this error "IOException: An unexpected network error occurred"

, ,
1

Hi,

On our Production environnement we have 2 IS (these are not real clusters but they are identical and deployed as a group to be available switched by a load balancer).

We have a service flow which is used to read some files (these files are avaiblable from a shared file system).

The problem we met is sometimes the “pub.file:getFile” fails with the error below because the file can not be read :

java.io.IOException: An unexpected network error occurred

Strangely, the file can be read from the IS2 but not from the IS1… and few days after the resource is released as if the files has been locked.

Do you know why we meet this behaviour please ?

The services called are :
pub.file:getFile
pub.soap.utils:createXOPObject

Maybe a “close” action must be done somewhere after the call of createXOPObject ?

Regards

2

Over the web, i didn’t see any advice or instruction saying this was required :
pub.io:close

Any idea ?

Regards

3

Hi Cedric,

in general it is good practice to close things which have been opened when they are no longer needed.

In this case this means, after the result of getFiles is converted and/or mapped to another variable (not stream type), the file (handler) should be closed via pub.flie:close to free the resources on the file system.

Regards,
Holger

4

Hi Holger,
Thanks for your reply.

Yes it is a good idea to close the resource, but in my case the getFile uses “bytes”. May I be certain that the resource will be accessible and available from the consumer ?

pub.file:getFile → bytes
pub.soap.utils:createXOPObject
pub.io:close

5

Hi Cedric,

you should use pub.file:closeFile instead of pub.io.close.

Regards,
Holger

6

But where can I find it ?

In my webMethods 9.8, it is neither in the directory pub.file, neither pub.io.

Regards

7

Hi Cedric,

the Built-In Services Guide refers to pub.io:close, but this will only work for streams and eventually readers, not for bytes.

This might be either an synchronization issue between the two IS instances or a networking issue between the two IS instances and the shared filesystem.

Regards,
Holger