vote : Remote build cache experiment
Hello devs ! I have not yet moved forward with enabling remote caching for the build and tests in general. It is unclear to me if you are ok with trying it from the previous discussion. So I'll call a more formal vote: Are you ok with experimenting enabling remote build cache for james (ci write+local read) ? Deployment of the remote build cache would follow the documented plan https://docs.gradle.com/enterprise/maven-build-cache/#rolling_out_the_cache_in_your_organization TLDR; 1. move forward with the INFRA request to get our build cache node 2. test (read+write) with a few (2-3) volunteers locally (not enabled on CI) 3. enable write on CI 4, enable read for everyone - voting starts 2024-02-20 - voting ends 2024-02-27 This is lazy consensus, this vote can be vetoed (please motivate your veto), there will be a second formal vote to definitely enable the cache once the experiment has been conducted and there are some results to share. jean
[jira] [Created] (JAMES-4005) We are getting below error in jaems logs and how to fix it
mohan created JAMES-4005: Summary: We are getting below error in jaems logs and how to fix it Key: JAMES-4005 URL: https://issues.apache.org/jira/browse/JAMES-4005 Project: James Server Issue Type: Bug Components: James Core Affects Versions: 3.3.0 Reporter: mohan Fix For: 3.3.0 8:34:33.548 [34m[INFO ][0;39m o.a.j.p.n.BasicChannelUpstreamHandler - Unable to process request java.nio.channels.ClosedChannelException: null at org.jboss.netty.handler.stream.ChunkedWriteHandler.discard(ChunkedWriteHandler.java:168) at org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:192) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:121) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:784) at org.jboss.netty.handler.execution.ExecutionHandler.handleDownstream(ExecutionHandler.java:176) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582) at org.jboss.netty.channel.Channels.write(Channels.java:704) at org.jboss.netty.channel.Channels.write(Channels.java:671) at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:347) at org.apache.james.protocols.netty.NettyProtocolTransport.writeToClient(NettyProtocolTransport.java:104) at org.apache.james.protocols.api.AbstractProtocolTransport.writeResponseToClient(AbstractProtocolTransport.java:145) at org.apache.james.protocols.api.AbstractProtocolTransport.writeResponse(AbstractProtocolTransport.java:64) at org.apache.james.protocols.netty.BasicChannelUpstreamHandler.channelConnected(BasicChannelUpstreamHandler.java:111) at org.apache.james.smtpserver.netty.SMTPChannelUpstreamHandler.channelConnected(SMTPChannelUpstreamHandler.java:54) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:100) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.channelConnected(SimpleChannelUpstreamHandler.java:191) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:100) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) at org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:314) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-4005) We are getting below error in jaems logs and how to fix it
[ https://issues.apache.org/jira/browse/JAMES-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JAMES-4005. - Resolution: Duplicate https://issues.apache.org/jira/browse/JAMES-3984 > We are getting below error in jaems logs and how to fix it > -- > > Key: JAMES-4005 > URL: https://issues.apache.org/jira/browse/JAMES-4005 > Project: James Server > Issue Type: Bug > Components: James Core >Affects Versions: 3.3.0 >Reporter: mohan >Priority: Major > Fix For: 3.3.0 > > > 8:34:33.548 [34m[INFO ][0;39m o.a.j.p.n.BasicChannelUpstreamHandler - > Unable to process request > java.nio.channels.ClosedChannelException: null > at > org.jboss.netty.handler.stream.ChunkedWriteHandler.discard(ChunkedWriteHandler.java:168) > at > org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:192) > at > org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:121) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) > at > org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:784) > at > org.jboss.netty.handler.execution.ExecutionHandler.handleDownstream(ExecutionHandler.java:176) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582) > at org.jboss.netty.channel.Channels.write(Channels.java:704) > at org.jboss.netty.channel.Channels.write(Channels.java:671) > at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:347) > at > org.apache.james.protocols.netty.NettyProtocolTransport.writeToClient(NettyProtocolTransport.java:104) > at > org.apache.james.protocols.api.AbstractProtocolTransport.writeResponseToClient(AbstractProtocolTransport.java:145) > at > org.apache.james.protocols.api.AbstractProtocolTransport.writeResponse(AbstractProtocolTransport.java:64) > at > org.apache.james.protocols.netty.BasicChannelUpstreamHandler.channelConnected(BasicChannelUpstreamHandler.java:111) > at > org.apache.james.smtpserver.netty.SMTPChannelUpstreamHandler.channelConnected(SMTPChannelUpstreamHandler.java:54) > at > org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:100) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) > at > org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) > at > org.jboss.netty.channel.SimpleChannelUpstreamHandler.channelConnected(SimpleChannelUpstreamHandler.java:191) > at > org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:100) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) > at > org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) > at > org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) > at > org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) > at > org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:314) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: vote : Remote build cache experiment
+1, Thanks for your enthusiastic effort on the topic. Cheers, Quan Vào Th 3, 20 thg 2, 2024 vào lúc 16:07 Rene Cordier đã viết: > +1, > > If there is a chance to make our builds faster, I say we take it! Thanks > for this work :) > > Rene. > > On 2/20/24 15:18, Jean Helou wrote: > > Hello devs ! > > > > I have not yet moved forward with enabling remote caching for the build > and > > tests in general. It is unclear to me if you are ok with trying it from > the > > previous discussion. So I'll call a more formal vote: > > > > Are you ok with experimenting enabling remote build cache for james (ci > > write+local read) ? > > > > Deployment of the remote build cache would follow the documented plan > > > https://docs.gradle.com/enterprise/maven-build-cache/#rolling_out_the_cache_in_your_organization > > TLDR; > > 1. move forward with the INFRA request to get our build cache node > > 2. test (read+write) with a few (2-3) volunteers locally (not enabled on > CI) > > 3. enable write on CI > > 4, enable read for everyone > > > > - voting starts 2024-02-20 > > - voting ends 2024-02-27 > > > > This is lazy consensus, this vote can be vetoed (please motivate your > > veto), there will be a second formal vote to definitely enable the cache > > once the experiment has been conducted and there are some results to > share. > > > > jean > > > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
Re: vote : Remote build cache experiment
+1 Thanks for taking the lead on the topic! Best regards, Benoit On 20/02/2024 09:18, Jean Helou wrote: Hello devs ! I have not yet moved forward with enabling remote caching for the build and tests in general. It is unclear to me if you are ok with trying it from the previous discussion. So I'll call a more formal vote: Are you ok with experimenting enabling remote build cache for james (ci write+local read) ? Deployment of the remote build cache would follow the documented plan https://docs.gradle.com/enterprise/maven-build-cache/#rolling_out_the_cache_in_your_organization TLDR; 1. move forward with the INFRA request to get our build cache node 2. test (read+write) with a few (2-3) volunteers locally (not enabled on CI) 3. enable write on CI 4, enable read for everyone - voting starts 2024-02-20 - voting ends 2024-02-27 This is lazy consensus, this vote can be vetoed (please motivate your veto), there will be a second formal vote to definitely enable the cache once the experiment has been conducted and there are some results to share. jean - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: vote : Remote build cache experiment
+1, If there is a chance to make our builds faster, I say we take it! Thanks for this work :) Rene. On 2/20/24 15:18, Jean Helou wrote: Hello devs ! I have not yet moved forward with enabling remote caching for the build and tests in general. It is unclear to me if you are ok with trying it from the previous discussion. So I'll call a more formal vote: Are you ok with experimenting enabling remote build cache for james (ci write+local read) ? Deployment of the remote build cache would follow the documented plan https://docs.gradle.com/enterprise/maven-build-cache/#rolling_out_the_cache_in_your_organization TLDR; 1. move forward with the INFRA request to get our build cache node 2. test (read+write) with a few (2-3) volunteers locally (not enabled on CI) 3. enable write on CI 4, enable read for everyone - voting starts 2024-02-20 - voting ends 2024-02-27 This is lazy consensus, this vote can be vetoed (please motivate your veto), there will be a second formal vote to definitely enable the cache once the experiment has been conducted and there are some results to share. jean - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
