[
https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022521#comment-16022521
]
Keith Wall edited comment on QPID-7731 at 5/24/17 8:25 AM:
-----------------------------------------------------------
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}} that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty. I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
was (Author: k-wall):
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}}s that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty. I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
> Upgrade to Jetty 9.4
> --------------------
>
> Key: QPID-7731
> URL: https://issues.apache.org/jira/browse/QPID-7731
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch
>
>
> The version of Jetty used by the Java Broker is v8.1. This is now marked as
> EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an
> option now we are on Java 8). The Jetty API has changed substantially so
> the HTTP Management is probably going to need a deep rewrite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
