Should we be concerned if tests are failing depending on if Jenkins is less busy or more busy? As we get closer to the Boron release, I can only imagine the demand increasing.
Best Regards, An Ho -----Original Message----- From: Luis Gomez [mailto:[email protected]] Sent: Tuesday, July 26, 2016 10:08 PM To: Abhijit Kumbhare Cc: An Ho; Jamo Luhrsen; openflowplugin-dev; Anil Vishnoi Subject: Re: OPENFLOWPLUGIN Beryllium SR3 Distribution Test Failures So I repeated the cbench test when Jenkins was less busy today and it passed. Also when it fails I see this is the karaf log: 2016-07-27 04:58:02,092 | WARN | entLoopGroup-7-7 | HandshakeManagerImpl | 150 - org.opendaylight.openflowplugin - 0.2.3.Beryllium-SR3 | issuing disconnect during handshake [/10.29.13.16:39231] 2016-07-27 04:58:02,092 | INFO | entLoopGroup-7-7 | ConnectionConductorImpl | 150 - org.opendaylight.openflowplugin - 0.2.3.Beryllium-SR3 | OF handshake failed, doing cleanup. 2016-07-27 04:58:02,108 | INFO | Thread-111 | SessionManagerOFImpl | 150 - org.opendaylight.openflowplugin - 0.2.3.Beryllium-SR3 | context for invalidation not found 2016-07-27 04:58:02,123 | WARN | entLoopGroup-7-1 | OFFrameDecoder | 147 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.7.3.Beryllium-SR3 | Unexpected exception from downstream. java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method)[:1.7.0_101] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)[:1.7.0_101] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)[:1.7.0_101] at sun.nio.ch.IOUtil.read(IOUtil.java:192)[:1.7.0_101] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:384)[:1.7.0_101] at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:221)[96:io.netty.buffer:4.0.37.Final] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:897)[96:io.netty.buffer:4.0.37.Final] at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:242)[98:io.netty.transport:4.0.37.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:119)[98:io.netty.transport:4.0.37.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:564)[98:io.netty.transport:4.0.37.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:505)[98:io.netty.transport:4.0.37.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:419)[98:io.netty.transport:4.0.37.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:386)[98:io.netty.transport:4.0.37.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[97:io.netty.common:4.0.37.Final] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)[97:io.netty.common:4.0.37.Final] at java.lang.Thread.run(Thread.java:745)[:1.7.0_101] Which makes me think the issue could be in the cbench tool or the network in between. BR/Luis > On Jul 26, 2016, at 8:17 PM, Abhijit Kumbhare <[email protected]> wrote: > > Thanks! > > On Tuesday, July 26, 2016, Luis Gomez <[email protected]> wrote: > First worked as expected: > > https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-scalability-lithium-redesign-only-beryllium/967/ > > Second still fails so issue has to be investigated although I do not think it > is blocker: > > cbench: controller benchmarking tool > running in mode 'throughput' > connecting to controller at > 10.29.9.112:6633 > > faking 8 switches offset 1 :: 10 tests each; 12000 ms per test > with 10000 unique source MACs per switch > learning destination mac addresses before the test > starting test with 0 ms delay after features_reply > ignoring first 1 "warmup" and last 0 "cooldown" loops > connection delay of 0ms per 1 switch(es) > debugging info is off > controller msgbuf_read() = 0: closed connection … exiting > > > BR/Luis > >> On Jul 26, 2016, at 11:30 AM, Luis Gomez <[email protected]> wrote: >> >> The first is a test error, I fixed it and I re-triggered the job. >> >> The second I am not sure, I re-triggered to see if this is an sporadic or a >> real issue. >> >> BR/Luis >> >> >>> On Jul 26, 2016, at 10:11 AM, Abhijit Kumbhare <[email protected]> >>> wrote: >>> >>> Both are classified as non-critical (as per the test case) - but Luis can >>> answer better. First one is a create JVM plot fail (so should not be >>> critical) but has a message that will need to be reviewed (including >>> whether that particular test should be just rerun): >>> >>> >>> ConnectionError: ConnectionError(('Connection aborted.', error(111, >>> 'Connection refused'))) caused by: ProtocolError(('Connection aborted.', >>> error(111, 'Connection refused'))) >>> >>> The second looks harmless I think - as it is just missing the word RESULT >>> but does show the results in flows/sec. >>> >>> '10:16:57.487 8 switches: flows/sec: 85854 92914 81796 0 82911 >>> 84662 0 89093 total = 43.102496 per ms ' does not contain 'RESULT' >>> >>> >>> On Tue, Jul 26, 2016 at 9:52 AM, An Ho <[email protected]> wrote: >>> Hi OPENFLOWPLUGIN Team, >>> >>> There are some distribution test failures in Beryllium SR3 related to your >>> project. Could you or someone from your team please take a moment to mark >>> these issues in the spreadsheet [1] as "OKAY" to release or "BLOCKING" and >>> requires a respin and delay of Beryllium SR3. >>> >>> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-scalability-lithium-redesign-only-beryllium/966/ >>> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-cbench-performance-only-beryllium/1616/ >>> >>> Best Regards, >>> An Ho >>> >>> [1] >>> https://docs.google.com/spreadsheets/d/1hci5TMUPyB6PX8Al-fwfVqvs5SQVa2wZLja_7rKWN6o/edit#gid=1820514274 >>> [2] >>> https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Beryllium_SR3_Download >>> >>> >> > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
