Can you upload a small reproducible test case? It sounds like you have one already - you can attach it as a tar.gz or .zip to this thread.
I took a quick look through the JIRAs on httpgateway and couldn't find anything there, but it'd really help if I had your full test case.
It is strange that it works from a browser rather than the ajax client. Could you post a TRACE server.log of both the browser based request and the failed ajax request? Please make sure you enable TRACE on the jboss.web component.
Sorry it has taken me so long to get back to you. Unfortunately, I cannot provide example code. I'll try and build some sample code, but the key here is separate servers. I'm sure you would have the same issue that I've found.
I've been using ESB since 2007 to wrap 3rd party software applications and make them available via ESB. Things have been working well until this problem came up.
I can describe my simple deployment.
A MySQL database server with JUDDI, user, and data database.
An ESB 4.12 server "A" Microsoft Server 2008 R2, Java 7u51, everything is 64bit Database Realm.
An ESB 4.12 server "B" Microsoft Server 2008 R2, Java 7u51, everything is 64bit Database Realm.
Both ESB Services run under the same windows service account.
All services use the security Database realm and basic authentication.
Two services: For simplicity, lets name them
Initial configuration that failed:
Server A contains a war file to provide an interface for users wishing to select and configure the processes that will be run.
Server B contains the http gateway for the "Router" Service. The gateway is a simple router to select which service to run. The router is not the ESB router because it was built when we were running Java 7 and ESB 4.9 which didn't support Drools with Java7. (Yes, I understand 4.12 fixed that issue) So, it creates a Service object and uses the Invoker to send an async message to the Converter on Server B. You should note that no exceptions are thrown while using the Invoker.
Both servers have a custom Realm for security that is tied to a database.
What did work was calling the proxy directly from the browser on a remote client by entering its URL. It asked for credentials and that worked, the credentials passed, and the service ran.
Same as the first except move the HTTP Gateway to ESB Server A.
This situation worked. The service complained about the credentials being passed and then checked them for itself and ran the service.
I've had this running for the last month.
Moving on to a new most likely related issue:
I've now deployed this to our production server environment.
The call to the HTTPGateway works, the service executes, but I am now getting an Unresponsive EPR JMSEpr for both the HTTPGateway service name and the selected service on service B. So, eventually, the HTTPGateway returns a 500 because the "Router" service never returned.
After having spent 6 business days trying to figure this out, I'm pretty worn/stressed out.
So, on the production deployment:
The httpgateway is called.
The security check passes
the service is started
The first action (system print) dumps the message
The second action correctly determines which service to call and then gets the correct information from JUDDI
At this point, I see an EPR Helper message and then Unresponsive EPR JMSEpr (with the correct JUDDI info)
At some point, I also see an UnresponsiveEPR JMSEpr for the service with the gateway. (I configured it with both an HTTP Gateway and a JMS ESB queue.
I'm not sure why it is calling the JMS Queue on this service. There is no need and none of my code initiated it.
Eventually, an exception is thrown about no response for the Router service, so the gateway returns a 500 to the client.
The ESB, as it should, continues to try and call the service on Server B.
That all tells me that the httpgateway router is actually getting the message in to the local JMS handler because it then tries to resend up to ten times.
So, why is ServerB not responding. BTW. The logs on server B do not print out anything. It is not being called.
All I get is UnresponsiveEPR JMSEpr for the correct address.
And no, I have checked the JUDDI DB and all services registered from each ESB server are correct. There are no duplicates.
Other steps taken:
* I had the IT folks open all ports on both machines in case a port was being blocked.
* I removed all the security from server B, so no credentials were required to call the "Converter" service.
* I rolled both Server A and B back to ESB 4.10. Same failure.
* tried Java 7U45 both 64 and 32bit
* I tried reconfiguring the providers
I finally had to move the services on Server B to Server A. and I took server B offline. That works just fine. Everything runs on the same server.
The only issue is that I need to be able to deploy the services that were on Server B across many servers to handle the workload. Again, they run third-party software that processes data. Each service can take tens of minutes to execute.
I'm not too happy with ESB at this point.
It appears to me that JMS is not working at all between the machines, but I'm not getting any exceptions anywhere except the UnresponsiveEPR...
I know that deploying services to different machines and deploying the same service on multiple machines should work. That I why I have been using ESB. I have not required that until now. I tested it way back in ESB 4.6 across three machines. It worked just fine (no security). It should work today, but does not.
This should be a very basic situation for ESB.
But, I suspect it is a JMS failure, so my next step is to reconfigure a different JMS. What could block JMS from going between machines on port 1099?
I would suspect that it is a Java 7U51 problem, but I'm running that on both system. As I mentioned above, I've ruled that out already.
Ok, so this second issue that I raised was due to failure to execute "trust but verify" on my part. I trusted IT to open the ports for JBoss. They confirmed the ports were open between the machines. When I finally checked them a little while ago, I found the firewall settings were not allowing JBoss ESB Servers to talk with each other! Once I opened the ports things worked.
This does not remove or answer the initial posting though. That is still an issue. I'll try and build some example code shortly and post it.
If you can get us some sample code, we can definitely take a look.