-----Original Message-----
From: JAVA400-L <java400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of James Lampert
Sent: Friday, May 31, 2019 6:45 PM
To: Java 400 List <java400-l@xxxxxxxxxxxxxxxxxx>
Subject: Weirdness with our Tomcat webapp, at only one customer

We've got a customer with a problem. And I can't make head or tail of it.

The Tomcat-based webapp on our CRM product makes a call to maps.googleapis.com:
https://maps.googleapis.com/maps/api/geocode/json?key=<REDACTED>&addre
ss=<REDACTED>

In every other installation of the product, it works just fine, under Java 6, Java 7, and Java 8 JVMs.

But on this one customer box, it fails, . . .

The problem continues: the Tomcat-based webapp consistently fails to access maps.googleapis.com for one customer (regardless of whether I run Tomcat under Java 7 or Java 8), but works fine everywhere else, under Java 6, 7, and 8, under OS releases from the current one all the way back to V6R1.

I've worked up a native test, using Scott Klement's HTTPAPI, plugging the above request into his EXAMPLE3 program that demonstrates https. I had hoped that it would fail in the same way, and I might find something in the diagnostics, but instead of failing, it consistently works perfectly.

And our Java specialist gave me a simple JAR, runnable from a QShell command line, that sent the same request, the same way the webapp does. And *it* fails consistently, except that it always seems to fail with the "Failed to connect" message, rather than the "Unable to find acceptable protocols" message, whereas the webapp switches between the two messages, seemingly at random.

Could there be some LICPGM that's missing, that would only affect the ability of Java to connect to the web service, but leave HTTPAPI unaffected?

--
JHHL

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].