web service installer error

[jlokanis]

When I install my application that includes a web service I am getting the following error at the end of the installation when the installer tries to install the web service component:

Can anyone tell me what could be causing this?

I am building this application with LV2015 and am installing on a Windows7 machine.

[Meekshow]

Hi John,

LabVIEW error 56 is a timeout error. This error can commonly occur if network cables are not properly connected or if the Machine Access List is not properly configured.

These and other commonly found causes of error 56 can be found in the folllowing Knowledge Base article:

http://digital.ni.com/public.nsf/allkb/D90C4F99C1EF3F6A86256E4A0080A120

Please let us know if this resolves your issue.

[jlokanis]

This machine is a VM running on a server.  Network connectivity is not an issue.

The EXE's INI File has the following settings:

server.tcp.enabled=TRUE
server.tcp.access="+127.0.0.1;+localhost;+*"

But, that should not matter because the error is occuring when the installer tries to start the web service, not my EXE.

So, there is clearly a bug in software written by NI, not me. Can you please tell me what the POSTMultipart.vi is trying to do so I can figure out what is timing out?

[Meekshow]

Hello again John,

The POSTMultipart VI sends a web request submitting data or files using the HTTP POST method to a server to let the server know the details of your application. This data transfer can take time depending on your application, and if this transfer takes longer than 10 seconds you will receive the timeout error.

You can read more about the VI here: http://zone.ni.com/reference/en-XX/help/371361G-01/lvcomm/http_client_postmultipart/

The attached zip file contains a post installer with a 30 second timeout. Hopefully that will be long enough to complete the HTTP POST.

[jlokanis]

Ok, so some part of the code in the installer is trying to talk to a web server. (I am going to assume this is the NIApplicationWebServer service that gets installed with the runtime engine).  And you are telling me that the timeout in that code was set too short and is causing this issue?  And this EXE you attached is a replacement for that part of the installer?  If so, how do I use this?  Where to I put this file or replace an existing file so when I build my installer, this new version with the longer timeout gets used?

Also, I just want ot be clear about what is happening here becasue I think there might be a miscommunication:

I have created a LabVIEW application that includes a web service component.

I have built that applcation into an EXE.

I have built an installer (using the provided tools in the project) to install this exe on a target computer that has the LabVIEW 2015 Runtime already installed on it.

The installer (built by LabVIEW 2015) runs something at the end of the installation process to deploy the web service included in the exe I built.

This 'deploy' process is running into a timeout error beacause the web server it is trying to talk to is not responding. (according to you previous reply).

Is it possible that the web server that the installer is trying to talk to is not working correctly?

If so, is there some way to test it?

[Meekshow]

Hi again John,

The web server is likely functioning correctly, and it is likely your installer is as well. The issue isn't that the server is not responding, it is that the data being transferred using the POST command is taking longer than the time allotted in the timeout of the function.

The exe was for a different application, that was my mistake.

May I ask what version of LabVIEW you are running?

[jlokanis]

I did notice one thing about my web service that might be related to this issue.  The size of the contents of the folder where the web service is deployed is ~16MB.  This appears to be due to a lot of static linking between classes in my application and the web service code.  I am looking into how to reduce this linking but I suspect the timeout issue is due to the size of this folder.  I suspect that the web service deploy code that is built into the installer did not anticipate such a large amount of code in a web service and therefore has too short of a timeout.

This should be a CAR to increase the timeout or to recode the deploy part of the installer so it adapts to web services with larger code bases.

[sassyaspy]

Hi John,

We're working on filing a CAR for the timeout you're experiencing on deploy--I think you're right about the large code base being a factor here. However, currently we don't have any code that reproduces the problem. If you are able to do so, would you attach what you feel is relevant here? Otherwise I'll work on making something similar to showcase the problem.

[jlokanis]

Unfortunatly I am not at liberty to share the code.  I suppose an example could be built using AF.  The key is that the web service VIs are sending messages to actors and those messages are statically linked to the actor classes, thus causing the web service to need a copy of the actor's full codebase.

I have been able to decouple some of the messages and reduce the footprint of the web service install to 11MB.  As a result, I only get the timeout when installing to slower machines.  So, I am convinced the timeout is directly related to the amound of code in the web service install folder after deployement.

Can you look at the VI in question and see if it just has an arbitrary timeout or if it is activly tracking the install process?  I suspect it is set to something like 30 seconds with the assumption that it could never take that long...

Also curious why copying 15MB of files would ever take that long.  I bet there is some other processing going on as well...

[sassyaspy]

That's a good place to start, thank you for the detail.

Earlier in this thread, meekshow attached an EXE that can be used as a post-install action to increase the timeout of the deployment. By default, POSTMultipart.vi has a timeout of 10s--his attached EXE increases that timeout to 30s. To use it in your installer, add it as a post-install action in the Advanced section of the build spec: