Open dfarina opened 11 years ago
When I call the toString()
on the HttpResponse after executing the request, I get this:
HTTP/1.1 400 Bad Request [Server: Apache-Coyote/1.1, Transfer-Encoding: chunked, Date: Wed, 07 Aug 2013 17:36:14 GMT, Connection: close]
Off the top of my head... wrong number of arguments to the subroutine. It's tough to say without knowing what's happening on the server side. It appears that you're just sending one huge argument. Does the subroutine signature only have a single argument? It's also possible that the request may exceed some size restriction in Unidata. Anything in the Hydra server logs?
See above. This should actually be in the HydraClient repo, since it's technically not even getting to Hydra.
Edit: And no, nothing generates in the Tomcat logs.
Actually, I just looked at the access log. I have a whole lot of these...
IP.ADDRESS.SECRET - - [07/Aug/2013:10:35:52 -0700] "POST null null" 400 -
To answer your questions above, I can send through larger requests without a problem, and if we skip over going through Tomcat, the Unidate routine successfully processes the request. Also, there is one giant argument, but 4 arguments come back. So there's something wrong with communication... it is possibly Tomcat's fault. Maybe it disagrees that this is a valid request?
Alright, let's back up... Subroutine calls have worked before, right? If they've worked on other servers, but not this, how do the configurations compare, port, host, etc? Maybe a variation is overlooked in building the request. If they've worked on this server, but not for this subroutine, how do the calls compare between those that have worked and this one?
Thanks!
Well, everything works perfectly except for the string above and one other one. All other subroutine requests are dandy. I even tried getting rid of all the strange characters like "#" in the string to no avail.
OK, so were dealing with edge cases at this point. I wonder if something isn't being encoded in an acceptable way. Have any successful requests been made to the same subroutine on this server? We should know that there's nothing necessarily wrong with the subroutine. We might have to start comparing the content to track down the problem. I think you're on the right track with the "#"'s. On the other hand, what if the problem isn't what's being sent, but what's being returned.
I have confirmed that the request that produce errors aren't even reaching the deployed Hydra instance, and Tomcat is instantly rejecting them with a 400 error above back to HydraClient.
The crazy thing is if I split up the request into 4 separate requests, it works.
Okay, I finally found a way to hit the Hydra instance being served.
A status code of 400 means that the http request is malformed, or otherwise doesn't obey protocol. Since I cannot determine why, I tried sticking the packed arguments array into a StringEntity instead of dumping it as a parameter in the URL. On the server side, the string has to be extracted from the request's InputStream, but it looks like this is the solution to the problem.
To be honest, what I'm about to do will qualify as a hack, because I'm only concerned about a single API call in Hydra, but I will commit the code when I'm finished. This will also be a fundamental change in the communication between the Client and Server instances, so I don't know how you feel about adopting it.
I get an exception thrown for issuing a request with the old "EXAMPLE" Unidata routine:
This is thrown when the following string is passed in as an argument: