Unauthorized error (401) under heavy load

[TimMaltGermany]

Hi, not sure whether this is an error or not, but I would appreciate any assistance you might provide: I sometimes get the error shown below when my Python service is under very heavy load. The service tries to send back its result to another service using this command: res = eureka_client.do_service( app_name=SOME_SERVICE, service='/projections/' + str(projection_id), method="PUT", headers={'Content-Type': 'application/json', 'Authorization': jwt_id_token}, data=json_term.encode("utf-8"), timeout=10 ) this usually works, but every once in a while it throws to error below. I already tried increasing the timeout to no avail. Do you have any other suggestions as to what may be going on? Thanks.

Error listing:

Traceback (most recent call last):
  File "/usr/src/app/api.py", line 43, in send_result
    res = eureka_client.do_service(
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/eureka_client.py", line 1310, in do_service
    return get_event_loop().run_until_complete(do_service_async(app_name=app_name, service=service, return_type=return_type,
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/eureka_client.py", line 1180, in do_service_async
    res = await cli.do_service(app_name=app_name, service=service, return_type=return_type,
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/eureka_client.py", line 937, in do_service
    return await self.walk_nodes(app_name, service, prefer_ip, prefer_https, walk_using_urllib)
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/eureka_client.py", line 894, in walk_nodes
    return await obj
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/eureka_client.py", line 929, in walk_using_urllib
    res: http_client.HttpResponse = await http_client.http_client.urlopen(
  File "/usr/local/lib/python3.9/site-packages/py_eureka_client/http_client.py", line 148, in urlopen
    res = urllib.request.urlopen(req._to_urllib_request(), data=data, timeout=timeout)
  File "/usr/local/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.9/urllib/request.py", line 523, in open
    response = meth(req, response)
  File "/usr/local/lib/python3.9/urllib/request.py", line 632, in http_response
    response = self.parent.error(
  File "/usr/local/lib/python3.9/urllib/request.py", line 561, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.9/urllib/request.py", line 641, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 401: Unauthorized

[keijack]

It seems that the the service you call return a 401 error? I think you could try to find the access logs an the target service component and try to find out which one return a 401.

[TimMaltGermany]

Thanks for your reply.  I had checked the logs of the other service already, but will again in 2 weeks when i am back at work. Am 04.08.2022 10:05 schrieb Keijack @.***>: It seems that the the service you call return a 401 error? I think you could try to find the access logs an the target service component and try to find out which one return a 401.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[TimMaltGermany]

I checked again and cannot find any such messages in the other relevant services (registry or service that is called). What I did notice however, is that the problem occurs pretty much exactly every five minutes during heavy load. I checked all the config options, but cannot find any code that sets a timeout of 300 seconds. It almost looks as if the heartbeat does not get through? @keijack Do you have an idea what might be the cause of this strange behavior?

[TimMaltGermany]

I will close this issue as I cannot provide any further information and have found a (temporary) work around.