Cannot flush closed output stream and GIT

SCM-Manager
1

Hi,

I have to issues with the SCM server (2.46.1) at the moment, I cannot explain to myself:

  1. In the syslog file there lots of entries of that kind:

2023-12-05 18:26:07.547:WARN:oejs.HttpChannel:qtp124313277-57: handleException /scm/repo/svn/MyRepository/!svn/vcc/default java.io.IOException: Cannot flush a closed output stream

Can anyone tell where this come from, how to fix it, or at least, what log level where I have to change such that it is not written to the log anymore?

  1. The scm-manager.log contains exceptions like:
2023-12-05 18:09:16.311 [ScmEventBus-1-6] [          ] ERROR com.github.legman.EventBus - ScmEventBus-1 - could not dispatch event: RepositoryHookEvent{repository=svn/MyRepository(4oTq0DW2fi), type=POST_RECEIVE} to handler SynchronizedEventHandler{null, public void sonia.scm.repository.GitRepositoryConfigInitializer.initConfig(sonia.scm.repository.PostReceiveRepositoryHookEvent), true}
java.lang.reflect.InvocationTargetException: null
        at jdk.internal.reflect.GeneratedMethodAccessor44.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.github.legman.InvocationContext.invoke(InvocationContext.java:108)
        at com.github.legman.InvocationContext.proceed(InvocationContext.java:101)
        at com.github.legman.micrometer.MicrometerInvocationInterceptor.invoke(MicrometerInvocationInterceptor.java:47)
        at com.github.legman.InvocationContext.proceed(InvocationContext.java:99)
        at com.github.legman.EventHandler.handleEvent(EventHandler.java:103)
        at com.github.legman.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:52)
        at com.github.legman.EventBus.dispatchSynchronous(EventBus.java:452)
        at com.github.legman.EventBus.lambda$dispatch$1(EventBus.java:444)
        at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120)
        at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: sonia.scm.repository.api.HookFeatureIsNotSupportedException: BRANCH_PROVIDER is not supported
        at sonia.scm.repository.spi.HookContextProvider.getBranchProvider(HookContextProvider.java:96)
        at sonia.scm.repository.api.HookContext.getBranchProvider(HookContext.java:86)
        at sonia.scm.repository.GitRepositoryConfigInitializer.initConfig(GitRepositoryConfigInitializer.java:56)
        ... 16 common frames omitted

I have GIT repositories completely deactivated, so maybe this is a bug? However, even it can be fixed, it is not easy to update to a newer version, so maybe also here, this can be deactivated somehow?

Thanks,
Markus

2

Hi, thanks for your questions.

Your first point has been fixed (and I’m somewhat sorry to say this) in 2.47.0. The good thing is, that this exception has no relevance. It should be possible to suppress this warning by adding a specific logger for this class in your logging.xml file:

<logger name="org.eclipse.jetty.server.HttpChannel" level="ERROR" />

But this will suppress all other warnings from this class, too.

I struggle a bit with your second point: I have no idea, how it can be possible to get this kind of exception without a git repository. This stack is located in a block that will only be entered, when a changed repository is of the type git. I wanted to check what happens, if you disable git with an existing git repository just to find out, that this should not be possible in SCM-Manager. So I’m a bit lost. Maybe a trace log could help at this point. If you know how to reproduce this log, would you be so kind to install the “Support Plugin”? This will give you another menu item “Support” in the Administration section. Here you can start the trace log, reproduce the exception, and than stop the trace again. You will get a zip file with the trace and some more information about your basic SCM-Manager setup (for example the installed plugins), but we would be totally happy with the log file alone.

Your last sentence concerned me: Can you elaborate your statement, that it is not easy to update SCM-Manager? This is definitely something we would like to avoid and if we could simplify some impediments, we would be glad to do so.

We would love to hear back from you!

René

3

Hi René,

thank you for the quick reply.

I tried to add the line you suggested to the logging.xml file. Unfortunately, it did not suppress the warning so I tried to add another line:

<logger name="oejs.HttpChannel" level="ERROR" />

Again, this does not “solve” the issue. Do you have another idea what I can add until I am allowed to update (see below about this topic)?

About the Support Plugin and my statement about updating: I am working for a company doing medical devices. According to their QM team, I cannot simply update the SCM-Manager as I like so I have to orchestrate with their responsible people because they have to provide the exact version for their audit. However, certainly it is possible to update but this would need some time and organisation.

Best,
Markus

4

Hi Markus,

you are definitely right here, though I have to admit that I don’t know exactly why. SCM-Manager uses Slf4j exactly as Jetty does, but somehow these logs escape the configuration. There are other ways to configure Jetty’s logging, but I get none to work at the moment.

I don’t know about your repositories, but the log only appears when the gzip compression for SVN is enabled (that’s why this escaped our attention for so long). Maybe (if your repositories aren’t too big), it might be an option to disable this in the global settings until you can update.

Your reason to not update SCM-Manager on a ragular basis is one of the few I can accept :wink:

By the way, the second exception you reported has also been fixed in 2.47.0 (the check I mentioned was added after 2.46.1 and therefore I was confused how this could happen).

I hope that SCM-Manager serves you quite well nonetheless and feel free to contact us again, whenever you notice something.

Have a great day!
René