[jira] [Commented] (QPID-8097) NullPointerException in AMQP 1.0 plugin using OpenJDK
[
https://issues.apache.org/jira/browse/QPID-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369916#comment-16369916
]
Artyom Safronov commented on QPID-8097:
---
Sorry for the belated response.
I can not provide my code because it is commercial. But code required to
reproduce the issue is trivial.
First of all the broker has to be started. In my case it is started as
embedded. But I think it does not matter and you can run it manually.
Then there must be code that tries to create a connection to the broker. That
is it.
> 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
[jira] [Commented] (QPID-8097) NullPointerException in AMQP 1.0 plugin using OpenJDK
[
https://issues.apache.org/jira/browse/QPID-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358273#comment-16358273
]
Keith Wall commented on QPID-8097:
--
Sorry for the jargon. By "using AMQP 1.0 against Broker-J" I simple meant
using an AMQP 1.0 messaging client library with Broker-J thus taking advantage
of the Broker's AMQP 1.0 support, rather than the older AMQP protocols (which
remain supported). A great deal of work was done in the AMQP 1.0 protocol
layer for 7.0, including addressing some quite serious shortcomings in memory
management that could lead to OutOfMemoryError related to direct memory. Also
there were a number of areas where the Broker was not conforming to the
specifications - these were addressed too.
With regard to the API for starting an embedding the Broker, it is true that we
took the opportunity to rework it for 7.0. What was there had rather evolved
over time and was quite ugly. Continuing to support the old API meant hanging
onto to too much baggage, so I am afraid this was a breaking change.
Apologies for pain in adapting to it. There is an example here:
https://cwiki.apache.org/confluence/display/qpid/How+to+embed+Qpid+Broker-J
Turning back to your problem, do you have a minimal executable reproduction
that shows the problem?
> 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
>
[jira] [Commented] (QPID-8097) NullPointerException in AMQP 1.0 plugin using OpenJDK
[
https://issues.apache.org/jira/browse/QPID-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355309#comment-16355309
]
Artyom Safronov commented on QPID-8097:
---
Please clarify what "using AMQP 1.0 against Broker-J" phrase means.
I know that 7th version of Qpid have been released with major improvements and
fixes. But I continued to use 6th one because of changes in API (first of all
Broker class). And that issue is the only severe problem I have faced with.
On my PC I have Oracle JDK installed and also there is a dedicated server for
CI that has OpenJDK installed. The defect have been found on that server
(locally all is fine). So at first OpenJDK was upgraded and after that (because
of it did not helped) was replaced with Oracle JDK.
At the moment we use Qpid only in the development environment.
I have heard about minor differences between OpenJDK and Oracle JDK but in the
real life they have more. :)
Qpid is embedded through creating instance of Broker class with all specific
options.
> 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
>
[jira] [Commented] (QPID-8097) NullPointerException in AMQP 1.0 plugin using OpenJDK
[
https://issues.apache.org/jira/browse/QPID-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
>
