Stupidity and Stuburnness [modified]
-
One of our ASP.NET web applications is supposed to use a java web service developed by another team. However, the service returns session errors about 50% of the time in development environment (credit to the jave team, at least it is failing at a consistent rate :-) ). But it works fine in formal test and production environments. Stupidity: As it turns out, when this java web service is called, it makes two calls to another java web service to do the work, and the second java web service is load balanced. The first call establishes a session with the second java web service on one of the two load balanced physical servers, the second call tries to use the established session, but 50% of the time the request landed on a different physical server, hence the session error. In formal test and production environments, back-doors are open to ensure that request to the second java web service is made directly to one physical server and that's why it does not have the session error. Stuburnness: We requested that if the java web service can't be fixed to work properly, a similar back-door should be open in development environment so that we can get some work done. The answer is NO, instead we get a lecture about design principles, best practices, and beans/factories/containers/layers, etc. In other words, we are not worthy of using the java web service. To this day, we are disabling the code to call to the java web service in development environment, hoping everything will be fine in formal test and production environments. -- modified at 10:16 Wednesday 24th October, 2007
-
One of our ASP.NET web applications is supposed to use a java web service developed by another team. However, the service returns session errors about 50% of the time in development environment (credit to the jave team, at least it is failing at a consistent rate :-) ). But it works fine in formal test and production environments. Stupidity: As it turns out, when this java web service is called, it makes two calls to another java web service to do the work, and the second java web service is load balanced. The first call establishes a session with the second java web service on one of the two load balanced physical servers, the second call tries to use the established session, but 50% of the time the request landed on a different physical server, hence the session error. In formal test and production environments, back-doors are open to ensure that request to the second java web service is made directly to one physical server and that's why it does not have the session error. Stuburnness: We requested that if the java web service can't be fixed to work properly, a similar back-door should be open in development environment so that we can get some work done. The answer is NO, instead we get a lecture about design principles, best practices, and beans/factories/containers/layers, etc. In other words, we are not worthy of using the java web service. To this day, we are disabling the code to call to the java web service in development environment, hoping everything will be fine in formal test and production environments. -- modified at 10:16 Wednesday 24th October, 2007
That’s nuts, whatever one group needs to make it work, so does the other group. If the management does not agree, then they should insure that the group responsible fixes the problem so the second group never sees it. In other words, they should have tested it under the conditions which group 2 requires before passing it on to them. That is best practices and et cetera, as not doing so waste everybody’s time and cost the company time and money. I hope it works out, but not being able to test properly during the development phase is a very bad thing.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
One of our ASP.NET web applications is supposed to use a java web service developed by another team. However, the service returns session errors about 50% of the time in development environment (credit to the jave team, at least it is failing at a consistent rate :-) ). But it works fine in formal test and production environments. Stupidity: As it turns out, when this java web service is called, it makes two calls to another java web service to do the work, and the second java web service is load balanced. The first call establishes a session with the second java web service on one of the two load balanced physical servers, the second call tries to use the established session, but 50% of the time the request landed on a different physical server, hence the session error. In formal test and production environments, back-doors are open to ensure that request to the second java web service is made directly to one physical server and that's why it does not have the session error. Stuburnness: We requested that if the java web service can't be fixed to work properly, a similar back-door should be open in development environment so that we can get some work done. The answer is NO, instead we get a lecture about design principles, best practices, and beans/factories/containers/layers, etc. In other words, we are not worthy of using the java web service. To this day, we are disabling the code to call to the java web service in development environment, hoping everything will be fine in formal test and production environments. -- modified at 10:16 Wednesday 24th October, 2007
nice problem it is not big problem i have a great solution for this problem. use Entry exit point when it call another web service.when it'll call load balance service then use Exit point and here save all information regards to the session. when it connect previous one then use entry point here invoke all information regards to the session. useing above idea where the session started.it'll save on user M/c then we dont need to maintain session in server end.