nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Intemittent Submit issue in custom CGI

andyRDX

We have a very peculiar problem in our environment. In one of our workflow we have a cgi file where we collected the metadata from the user. This CGI post the data to another CGI which saves the metadata in teamSite.
Now the issue is, sometimes the metadata is not getting saved in TeamSite.

Till now I have done the following troubleshooting
1) Put debugs in the 2nd cgi to check if there is any issue while saving the metadata - The 2nd cgi does not get a hit when this issue happens
2) I have checked the data that i am passing from the 1st CGI using a javascript alert just before the post - There is no issue in the data.
3) So the main issue is while doing a HTTP POST from 1st CGI the request is not reaching the 2nd CGI. But this happens only sometimes, other times the code works perfectly.
4) I have also checked the access and error logs of iwui, Whenever this issue occurs there is no record in the access log file for the 2nd cgi, while in normal case i see a line in the access log for the 2nd CGI.
5) I have checked at the server level also, the server statistics are quite OK.
5) We had also put a network sniffer to identify if there is any issues in network. The network team says that they see resets coming from the Servers.
So the issue again comes back to application side.

Did anyone face this kind of issue earlier. I am right now clueless, what more i can check. Is this a performance issue in TeamSite or some network or server level issue.

Here is the technical details of our environment:
1) TeamSite 6.7.1 SP1
2) Sun Solaris 9

Find more posts tagged with

Comments

Rick Poulin

I'd suggest posting the relevant piece of code. I'm particularly confused about how you made sure your data was correct right before the post by using a _javascript_ alert.

andyRDX

I am printing all the FORM values in the alert before posting the FORM from javascript. This is
Why I am saying this is not a data issue is:
1) The same data gets posted if i try again
2) Even if there is something wrong in the data, the access log or my custom debug file should show a hit in the 2nd cgi file. which is not here

The main issue is not the data, but sometimes the 2nd cgi file is not getting a hit and i need some suggestion how to narrow down this to a performance issue in TeamSite or Performance issue in the unix server or a network issue. The code works perfectly for most of the time, only sometime it behaves like this.

Adam Stoller

The code works perfectly for most of the time, only sometime it behaves like this.

Did you ever consider that maybe you are getting lucky most of the time and that the code has problems?

I once worked at a company that developed most of their software [C code] on IBM RT's (a not very-well know Unix box, pre-dated the RS6000) and everything seemed to work fine. They then started compiling the software on Sun boxes (if I recall, this was pre-Solaris) and programs started exhibiting very odd and seemingly random behavior. The problem was that most of the code didn't have return statements so internally it just returned whatever was on the stack and on the RT that was always 0, but on the Sun boxes it could be either 0 or 1, it was truly random.

The moral being, just because it seems to work right most of the time - doesn't mean that the problem is in the environment - it could still mean that the problem is in the code.

andyRDX

I totally agree to what you are saying, But in that case there should be something in the access log saying that the 2nd cgi was hit and got a 5xx or 4xx response. Or the error log showing there was an error in the CGI. But this is not happening here, there is simply nothing in the log when the error happens.
So I was just asking, is there a way/tool to find where the HTTP post request is going/breaking, as the log suggest the request did not reach the application. And the network team is saying that the connection is getting reset by the Server.

TechLegend

hmm...quite tricky issue

Adam Stoller

I totally agree to what you are saying, But in that case there should be something in the access log saying that the 2nd cgi was hit and got a 5xx or 4xx response. Or the error log showing there was an error in the CGI. But this is not happening here, there is simply nothing in the log when the error happens.
So I was just asking, is there a way/tool to find where the HTTP post request is going/breaking, as the log suggest the request did not reach the application. And the network team is saying that the connection is getting reset by the Server.

You say you put debug statements in the 2nd CGI - did you try putting debug statements (writing to a log file) in the 1st CGI both before and after the call to the 2nd CGI? That should at least tell you whether the call to the 2nd CGI is even happening. If not, you need to add more debugging to your 1st CGI to determine where it is failing.