[ 
https://issues.apache.org/jira/browse/QPID-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354274#comment-16354274
 ] 

Keith Wall commented on QPID-8097:
----------------------------------

Thanks for reporting the problem.

Firstly, let me point out if you are using AMQP 1.0 against Broker-J, use 7.0.0 
(7.0.1 should be out in a day or two).   Literally scores of AMQP 1.0 defect 
fixes - many major - and improvements went into the v7.0.0 line.

Looking at the location of the NPE, I can't immediately see how you reach that 
situation. To reach that point in the object's lifecycle, there should have 
been a socket which was connected to the remote endpoint.    Even if the socket 
has been subsequently closed, the {{getNetwork().getRemoteAddress()}} ought to 
be returning an {{InetSocketAddress}}.  The javadoc says as much [1].

[1] 
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#getRemoteSocketAddress--

Do you generally have a problem with Broker-J on the OpenJDK (outside of the 
tests)?   IIRC the differences between Oracle JDK and Open JDK are few.  How 
exactly are you embedding the Broker?

  


 

> NullPointerException in AMQP 1.0 plugin using OpenJDK
> -----------------------------------------------------
>
>                 Key: QPID-8097
>                 URL: https://issues.apache.org/jira/browse/QPID-8097
>             Project: Qpid
>          Issue Type: Bug
>          Components: Broker-J
>    Affects Versions: qpid-java-6.1.5
>            Reporter: Artyom Safronov
>            Priority: Major
>         Attachments: Qpid stacktrace.txt
>
>
> An unexpected NullPointerException occures in AMQP 1.0 plugin at the first 
> attempt to connect to the broker using *OpenJDK*.
> The problem was found while running Qpid in unit tests that verify code 
> communicated with the broker through AQMP. There is a test case that starts 
> Qpid before each test and stops it after it. That test case verifies a module 
> that establishes a connection with the broker. The broker refuses the 
> connection because of NullPointerException (see the attached stacktrace). 
> Using *Oracle JDK* all tests run fine.
> +The first strange+ thing looks like this. Only a test that does the first 
> attempt to connect always fails. The rest tests run successfully although 
> Qpid are restarted. So the order of tests is not important. The project is 
> built using Maven and all its plugins are run within +a single process+ 
> (without fork ability).
> +The second strange+ thing is that the behaivor of Qpid slightly differs 
> using two different *OpenJDK* versions.
> In a case of *1.8.0_131* version the broker accepts a transport connection 
> but rejects "OPEN" frame with the next error:
> {code:java}
> io.vertx.core.impl.NoStackTraceThrowable: Error{condition=amqp:not-found, 
> description='Unknown hostname in connection open: 'default'', info=null}
> {code}
>  In a case of *1.8.0_161* version the broker rejects a transport connection 
> instantly with the next exception:
> {code:java}
> io.vertx.core.VertxException: Disconnected
>  at 
> io.vertx.proton.impl.ProtonClientImpl.lambda$null$0(ProtonClientImpl.java:80) 
> ~[vertx-proton-3.5.0.jar:?]
>  at 
> io.vertx.proton.impl.ProtonConnectionImpl.fireDisconnect(ProtonConnectionImpl.java:374)
>  ~[vertx-proton-3.5.0.jar:?]
>  at 
> io.vertx.proton.impl.ProtonTransport.handleSocketEnd(ProtonTransport.java:89) 
> ~[vertx-proton-3.5.0.jar:?]
>  at io.vertx.core.net.impl.NetSocketImpl.handleClosed(NetSocketImpl.java:345) 
> ~[vertx-core-3.5.0.jar:?]
>  at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:342) 
> ~[vertx-core-3.5.0.jar:?]
>  at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:200) 
> [vertx-core-3.5.0.jar:?]
>  at 
> io.vertx.core.net.impl.VertxHandler.channelInactive(VertxHandler.java:134) 
> [vertx-core-3.5.0.jar:?]
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1354)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:917)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:763)
>  [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
>  [netty-common-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
>  [netty-common-4.1.15.Final.jar:4.1.15.Final]
>  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463) 
> [netty-transport-4.1.15.Final.jar:4.1.15.Final]
>  at 
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
>  [netty-common-4.1.15.Final.jar:4.1.15.Final]
>  at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161-debug]{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to