#radu-m_error

1 messages · Page 1 of 1 (latest)

eternal cobaltBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1425467809894236312

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

kindred mesa
eternal cobaltBOT
patent prawn
#

To first answer the question, I don't think you can adjust that timeout, but I will try to confirm that while we chat.

Stepping back, I don't really understand the problem causing the timeout and how grpc/caching come into play. Why is it taking your backend >60s to respond to this connection token request?

kindred mesa
#

When I start my app, the S700 is disconnected from the internet.
However, I get multiple calls on my TokenProvider.getToken(ConnectionTokenCallback) to provide a token, and I attempt to connect to the backend multiple times.
Upon starting up, my app creates a gRPC channel to the backend using the hostname (eg. "abc.domain.com") and the port (eg. 50151).
The creation of the channel is successful, but my "get token from backend" requests throw:
java.net.UnknownHostException: Unable to resolve host "abc.domain.com": No address associated with hostname

This is because the device is not connected to the internet and the Java DNSResolver cannot identify the IP corresponding to the hostname.
The failure is stored in the "negative" DNS cache that holds all failed DNS requests. The TTL for any failed request is 300 seconds.

Upon getting the device connected to the internet, I get 2 more calls on my TokenProvider.getToken(ConnectionTokenCallback) to provide a token, since the device is now online and expects an online token (as opposed to the offline token it used initially).

Once my app attempts to connect to the backend to retrieve this token, because of the 300 seconds TTL on the "negative" DNS cache, I continue to get UnknownHostException until the 300 seconds elapse, the DNS cache entry gets ejected and the Java DNS resolver performs a successful resolution for "abc.domain.com" to its IP.

patent prawn
#

Interesting, this is not something I've heard of being a challenge before. Trying to wrap my head around, so going to think out lout a bit so you can correct any bad assumptions.

#

First, from context I understand you're building an "Apps on Devices" integration, you app is running directly on the S700 and using the handoff pattern for the payment flow.

#

Second, I interpret that you're operating in offline mode for some time as well. Are you collecting offline payments, too?

#

This connection failure (UnknownHostException), and the described DNS caching I expect is entirely on the S700, too

#

What I don't understand is how the reader/SDK detect being online, but the connection to your backend fails.

#

Is this due to the gRPC configuration you're describing, and can you say more about that if so? I don't understand what that means in practical terms for the endpoint providing the tokens on your backend.

kindred mesa
#

Yes to Apps on Device and Yes, we're collecting offline payments.
I recently upgraded my Stripe Java libraries, and that's when this started to be an issue.
Before, the device was not asking for a new connection token upon getting reconnected to the internet. I assume the offline token was good enough, for a while.
If the request to get a "fresh" connection token come in later, after the 300 seconds TTL, everything works as expected.

#

I guess the inner S700 are in Kotlin, and I'm using Java.
My gRPC connection uses InetAddress to resolve the IP address of the backend based on the hostname.
I looked over the javadoc for InetAddress:

#

and that "negative" cache is 300 seconds

#

I attempted to create my gRPC channel in a different way, even by extracting the IP address of the backend in a different way, and creating a different communication channel using the IP address. But this still doesn't work because the library still goes to InetAddress to uses that cache.

patent prawn
#

And your understanding is that this (300s negative dns ttl) is something we've set in the S700 host software?

#

Which versions of the android terminal SDK did you upgrade from/to?

kindred mesa
kindred mesa
# patent prawn And your understanding is that this (300s negative dns ttl) is something we've s...

I believe it's set somewhere in the JRE.
On Java 11, the file storing the TTL values is: $JAVA_HOME/conf/security/java.security

Now there might be a chance I'm getting this wrong, since this is not a device that we can tinker around with. We have to navigate based on the limitation imposed by the ecosystem. Which is fine, as long as there are some options to choose from when such a problem appears 🙂

patent prawn
#

I'm probably going to have to have you write in so I can pick this up as a case and work with the Terminal team directly with your example.

kindred mesa
#

I tried setting them inside the app:
static {
// Disable negative DNS caching
java.security.Security.setProperty("networkaddress.cache.negative.ttl", "0");

// Also reduce positive DNS caching
java.security.Security.setProperty("networkaddress.cache.ttl", "10");

}

But I recall getting some errors around permissions at that stage.

patent prawn
kindred mesa
patent prawn
#

But reading docs that sounds like a timeout related to gradle itself, not network calls inside the app

#

Let me take a look where that is currently

kindred mesa
#

I will be AFK for about 30 minutes, need to pick-up my kid from kindergarten 🙂

kindred mesa
#

I'm back now, if there's anything I can provide in addition to the above, please let me know.
In any case, thank you for writing back to me and trying to help!

patent prawn
#

Yep I'm talking with the person handling your case currently about escalating to my team to help you work on this

#

I'm not sure what options we have at our disposal here, but will work with the Terminal reader/sdk eng team to try to figure that out