You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 23, 2024. It is now read-only.
We are seeing deadlock issues where we are using LogglyAppender wrapped in an AsyncAppender. I was reviewing the LogglyAppender code to see if there's anything that might account for it there and noticed that connection.disconnect() is being called. From the Javadocs (http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#disconnect()), it looks like it might be worth considering not calling disconnect as the docs suggest it is a hint to connection that "Indicates that other requests to the server are unlikely in the near future". It's unclear what effect calling disconnect() will have but it seems in a case like ours where we are sending logging entries to Loggly frequently that it might be causing us to incur unnecessary overhead.
The text was updated successfully, but these errors were encountered:
I'm not sure that omitting the call to #disconnect() is the answer as that could cause a resource leak. Perhaps we could provide an option to cache the connection and call #disconnect() only when stopping the appender (similar to the behavior of SocketAppender).
We are seeing deadlock issues where we are using LogglyAppender wrapped in an AsyncAppender. I was reviewing the LogglyAppender code to see if there's anything that might account for it there and noticed that connection.disconnect() is being called. From the Javadocs (http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#disconnect()), it looks like it might be worth considering not calling disconnect as the docs suggest it is a hint to connection that "Indicates that other requests to the server are unlikely in the near future". It's unclear what effect calling disconnect() will have but it seems in a case like ours where we are sending logging entries to Loggly frequently that it might be causing us to incur unnecessary overhead.
The text was updated successfully, but these errors were encountered: