I have an ABL session that is constantly accessing a (missing) file in the working directory called "logging.config".
Here is partial "-y" output for the session.
C:\Progress\OpenEdge\oeide\eclipse\plugins\com.openedge.pdt.debug.core_11.7.5.00\abl\_debuglauncher.p jms/impl/errorhndlr.r jms/impl/header-message.r jms/impl/message.r jms/impl/message-consumer.r jms/impl/message-header.r jms/impl/msgreceiver.r jms/impl/session.r jms/impl/text-message.r jms/ptpsession.r OpenEdge/Core/Assert.r OpenEdge/Core/Assertion/AssertObject.r OpenEdge/Core/ByteBucket.r OpenEdge/Core/Collections/ICollection.r OpenEdge/Core/Collections/IIterable.r OpenEdge/Core/Collections/IIterator.r OpenEdge/Core/Collections/IMap.r OpenEdge/Core/Collections/ISet.r OpenEdge/Core/Collections/IStringKeyedMap.r OpenEdge/Core/Collections/IStringStringMap.r OpenEdge/Core/Collections/Iterator.r OpenEdge/Core/Collections/KeySet.r OpenEdge/Core/Collections/Map.r OpenEdge/Core/Collections/MapBackedCollection.r OpenEdge/Core/Collections/StringKeyedMap.r OpenEdge/Core/Collections/StringStringMap.r OpenEdge/Core/IAdaptable.r OpenEdge/Core/ISupportEncoding.r OpenEdge/Core/ISupportInitialize.r OpenEdge/Core/Memptr.r OpenEdge/Core/ServerConnection/IConnectionParameters.r OpenEdge/Core/ServerConnection/IServerConnection.r OpenEdge/Core/String.r OpenEdge/Core/StringConstant.r OpenEdge/Core/Util/BuilderRegistry.r OpenEdge/Core/Util/ConfigBuilder.r OpenEdge/Core/Util/MathUtil.r OpenEdge/Core/WidgetHandle.r OpenEdge/Logging/ConfigFileLoggerBuilder.r <<<<<<<<<< OpenEdge/Logging/Filter/ILoggerFilter.r OpenEdge/Logging/Filter/LogFilterBuilder.r OpenEdge/Logging/ILogWriter.r OpenEdge/Logging/ISupportLogging.r OpenEdge/Logging/LoggerBuilder.r OpenEdge/Logging/LogLevelEnum.r OpenEdge/Logging/VoidLogger.r OpenEdge/Net/HTTP/AuthenticatedRequest.r OpenEdge/Net/HTTP/AuthorizationHeaderBuilder.r OpenEdge/Net/HTTP/BuilderRegistry.r OpenEdge/Net/HTTP/ClientBuilder.r OpenEdge/Net/HTTP/ClientOptions.r OpenEdge/Net/HTTP/ConfigBuilder.r OpenEdge/Net/HTTP/ContentDispositionHeaderBuilder.r OpenEdge/Net/HTTP/ContentTypeHeader.r OpenEdge/Net/HTTP/ContentTypeHeaderBuilder.r OpenEdge/Net/HTTP/DefaultHeaderBuilder.r OpenEdge/Net/HTTP/DefaultHttpClientBuilder.r OpenEdge/Net/HTTP/DefaultRequestBuilder.r OpenEdge/Net/HTTP/DefaultResponseBuilder.r OpenEdge/Net/HTTP/Filter/Header/SetCookieSetHeaderFilter.r OpenEdge/Net/HTTP/Filter/Header/TransferEncodingSetHeaderFilter.r OpenEdge/Net/HTTP/Filter/Payload/BinaryEntityWriter.r OpenEdge/Net/HTTP/Filter/Payload/ClientSocketResponseWriter.r OpenEdge/Net/HTTP/Filter/Payload/ConnectRequestFilter.r OpenEdge/Net/HTTP/Filter/Payload/DefaultRequestFilter.r OpenEdge/Net/HTTP/Filter/Payload/JsonEntityWriter.r OpenEdge/Net/HTTP/Filter/Payload/MessageWriter.r OpenEdge/Net/HTTP/Filter/Payload/MultipartEntityWriter.r OpenEdge/Net/HTTP/Filter/Payload/MultipartFormEntityWriter.r OpenEdge/Net/HTTP/Filter/Payload/StringEntityWriter.r OpenEdge/Net/HTTP/Filter/Payload/XmlEntityWriter.r OpenEdge/Net/HTTP/Filter/Status/AuthorizationStatusFilter.r OpenEdge/Net/HTTP/Filter/Status/RedirectStatusFilter.r OpenEdge/Net/HTTP/Filter/Writer/DefaultMessageWriterBuilder.r OpenEdge/Net/HTTP/Filter/Writer/EntityWriterBuilder.r OpenEdge/Net/HTTP/Filter/Writer/EntityWriterRegistry.r OpenEdge/Net/HTTP/Filter/Writer/MessageWriterBuilder.r OpenEdge/Net/HTTP/Filter/Writer/RequestWriterBuilder.r OpenEdge/Net/HTTP/Filter/Writer/SetHeaderMessageWriterBuilder.r OpenEdge/Net/HTTP/Filter/Writer/StatusCodeWriterBuilder.r OpenEdge/Net/HTTP/HttpClient.r OpenEdge/Net/HTTP/HttpClientDecorator.r OpenEdge/Net/HTTP/HttpHeader.r OpenEdge/Net/HTTP/HttpHeaderBuilder.r OpenEdge/Net/HTTP/HttpHeaderCollection.r OpenEdge/Net/HTTP/HttpMessage.r OpenEdge/Net/HTTP/HttpRequest.r OpenEdge/Net/HTTP/HttpRequestDecorator.r OpenEdge/Net/HTTP/HttpResponse.r OpenEdge/Net/HTTP/IAuthenticatedRequest.r OpenEdge/Net/HTTP/ICookieJar.r OpenEdge/Net/HTTP/IHttpClient.r OpenEdge/Net/HTTP/IHttpClientLibrary.r OpenEdge/Net/HTTP/IHttpMessage.r OpenEdge/Net/HTTP/IHttpMessageWriter.r OpenEdge/Net/HTTP/IHttpRequest.r OpenEdge/Net/HTTP/IHttpResponse.r OpenEdge/Net/HTTP/ISupportCookies.r OpenEdge/Net/HTTP/ISupportProxy.r OpenEdge/Net/HTTP/Lib/ABLSockets/ABLSocketLibrary.r OpenEdge/Net/HTTP/Lib/ABLSockets/ABLSocketLibraryBuilder.r OpenEdge/Net/HTTP/Lib/ClientLibraryBuilder.r OpenEdge/Net/HTTP/MethodEnum.r OpenEdge/Net/HTTP/ProxyHttpClient.r OpenEdge/Net/HTTP/ProxyHttpRequest.r OpenEdge/Net/HTTP/RequestBuilder.r OpenEdge/Net/HTTP/ResponseBuilder.r OpenEdge/Net/HTTP/SemicolonParamHeaderBuilder.r OpenEdge/Net/HTTP/StatefulHttpClient.r OpenEdge/Net/HTTP/StatusCodeEnum.r OpenEdge/Net/HTTP/TransferEncodingEnum.r OpenEdge/Net/ISupportEncoding.r OpenEdge/Net/ISupportMultipartEntity.r OpenEdge/Net/ISupportTransferEncoding.r OpenEdge/Net/ServerConnection/ClientSocket.r OpenEdge/Net/ServerConnection/ClientSocketConnectionParameters.r OpenEdge/Net/ServerConnection/sockethelper.r OpenEdge/Net/ServerConnection/SocketReadEventArgs.r OpenEdge/Net/URI.r OpenEdge/Net/UriSchemeEnum.r
I suspect the culprit is the item identified above by "<<<<<". Can someone confirm?
Is that supposed to be doing I/O on disk? I think it is happening indirectly based on a dependency on OpenEdge.Net.HTTP. Ideally we would turn off the file system I/O. We don't currently need the logging functionality (and I'm not even sure what functionality is available).
We are running 11.7.5.
>As far as implementation goes, I noticed lots of static members in that "ConfigFileLoggerBuilder". Would it be possible to have a static method or
> property that adjusts the behavior of config and determines if config files should be read once per-session, or upon every REST call?
> As a side, is this "Consultingwerk" github repro the official one for OpenEdge API's? I've wondered that before. It is certainly the repo that comes
> up first in google searches.
Consultingwerk takes the Zip files from https://knowledgebase.progress.com/articles/Article/P9621 and puts them into github for better readability. There's not an official Progress one at this time.
Thanks for digging into that for me.
Here is performance profiling for the session that I'm working with.
The dependency on application logging seems to come from the OpenEdge.Net namespace for HTTP/REST. Our rest method calls are pretty quick, and we are starting to rely on it. The only performance issue is when we make lots of REST requests in loops. The file I/O that is associated with this logging can be a fairly significant portion of the total.
There are multiple factors involved. One is that we often host our session working directories on file servers (NAS). So repeatedly accessing the same file in the file system can create a network-related performance impact.
As far as implementation goes, I noticed lots of static members in that "ConfigFileLoggerBuilder". Would it be possible to have a static method or property that adjusts the behavior of config and determines if config files should be read once per-session, or upon every REST call?
I suppose I could manage my own static members as a workaround (eg. I might hold onto a long-lived copy of the same OpenEdge.Net.HTTP.IHttpClient and OpenEdge.Net.HTTP.IHttpRequest). But these things seem like they should be transient (unlike config, which is not edited often, and typically requires that an application be restarted.)
As a side, is this "Consultingwerk" github repro the official one for OpenEdge API's? I've wondered that before. It is certainly the repo that comes up first in google searches.
>As far as implementation goes, I noticed lots of static members in that "ConfigFileLoggerBuilder". Would it be possible to have a static method or
> property that adjusts the behavior of config and determines if config files should be read once per-session, or upon every REST call?
> As a side, is this "Consultingwerk" github repro the official one for OpenEdge API's? I've wondered that before. It is certainly the repo that comes
> up first in google searches.
Consultingwerk takes the Zip files from https://knowledgebase.progress.com/articles/Article/P9621 and puts them into github for better readability. There's not an official Progress one at this time.
Thanks again for the pointers.