[jira] [Commented] (QPID-8674) [Broker-J] Jms Selector Parsing - mulitple AND's
[
https://issues.apache.org/jira/browse/QPID-8674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885886#comment-17885886
]
Kyrre commented on QPID-8674:
-
Hello, sorry for the late comment.
You are absolutely correct, this is due to an error between the chair and the
keyboard. I encountered an error in one of our selectors, and tried to boil it
down to the simplest case I could do, and somewhere I flipped the assert.
I've looked more into this, and it seems to be the combination of brackets and
negation.
So an updated version of the code would be:
{code:java}
@Test
public void originalTest() throws ParseException {
final Filterable message = mock(Filterable.class);
when(message.getHeader("color")).thenReturn("red");
when(message.getHeader("price")).thenReturn(100);
when(message.getHeader("size")).thenReturn("large");
assertFalse(new JMSSelectorFilter("color = 'red' and not (price = 200)
and not (size = 'small')").matches(message));
}
{code}
This test fails.
This boils down to
{code:java}
final Filterable message = mock(Filterable.class);
when(message.getHeader("entry")).thenReturn("bbb");
assertFalse(new JMSSelectorFilter("true and not (false) and not
(true)").matches(message));
{code}
which also fails, as the matching returns true.
But, the code
{code:java}
final Filterable message = mock(Filterable.class);
when(message.getHeader("entry")).thenReturn("bbb");
assertFalse(new JMSSelectorFilter("true and (not false) and (not
true)").matches(message));
{code}
passes, as the matches method returns false.
This, as far as I can see, boils down to syntax. According to the spec,
selectors use the select part of SQL92, but looking into this issue, I had a
real problem finding out what the correct syntax really is.
The reason this is a problem for us, is that we use selectors that uses the
'like' operator with wildcards, and have several of them chained together,
possibly with some of them negated (in rare cases).
I don't know if this is really a bug or a mismatch/underspecification of the
selector spec. In any case, I would like to see either both the cases returning
the correct boolean value, or an exception thrown if the selector syntax is
wrong.
> [Broker-J] Jms Selector Parsing - mulitple AND's
>
>
> Key: QPID-8674
> URL: https://issues.apache.org/jira/browse/QPID-8674
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-9.2.0
>Reporter: Kyrre
>Priority: Major
> Attachments: selectorSyntax.patch
>
>
> When parsing a selector with 3 boolean expressions AND'ed together, the last
> expression is not taken into account.
> I have attached a patch file from the latest Github version of the main
> branch to demostrate the problem.
> In short, having a selector that evaluates (trueExpression) AND
> (trueExpression) AND (falseExpression) evaluates to TRUE.
> Patch of JMSSelectorFilterSyntaxTest.java below.
> [^selectorSyntax.patch]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8674) [Broker-J] Jms Selector Parsing - mulitple AND's
[ https://issues.apache.org/jira/browse/QPID-8674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyrre updated QPID-8674: Summary: [Broker-J] Jms Selector Parsing - mulitple AND's (was: Jms Selector Parsing - mulitple AND's) > [Broker-J] Jms Selector Parsing - mulitple AND's > > > Key: QPID-8674 > URL: https://issues.apache.org/jira/browse/QPID-8674 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-9.2.0 >Reporter: Kyrre >Priority: Major > Attachments: selectorSyntax.patch > > > When parsing a selector with 3 boolean expressions AND'ed together, the last > expression is not taken into account. > I have attached a patch file from the latest Github version of the main > branch to demostrate the problem. > In short, having a selector that evaluates (trueExpression) AND > (trueExpression) AND (falseExpression) evaluates to TRUE. > Patch of JMSSelectorFilterSyntaxTest.java below. > [^selectorSyntax.patch] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8674) Jms Selector Parsing - mulitple AND's
Kyrre created QPID-8674: --- Summary: Jms Selector Parsing - mulitple AND's Key: QPID-8674 URL: https://issues.apache.org/jira/browse/QPID-8674 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-9.2.0 Reporter: Kyrre Attachments: selectorSyntax.patch When parsing a selector with 3 boolean expressions AND'ed together, the last expression is not taken into account. I have attached a patch file from the latest Github version of the main branch to demostrate the problem. In short, having a selector that evaluates (trueExpression) AND (trueExpression) AND (falseExpression) evaluates to TRUE. Patch of JMSSelectorFilterSyntaxTest.java below. [^selectorSyntax.patch] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8657) [Broker-J] ACL - Posting unknown attributes leaves broker in bad internal state
[ https://issues.apache.org/jira/browse/QPID-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyrre updated QPID-8657: Summary: [Broker-J] ACL - Posting unknown attributes leaves broker in bad internal state (was: ACL - Posting unknown attributes leaves broker in bad internal state) > [Broker-J] ACL - Posting unknown attributes leaves broker in bad internal > state > --- > > Key: QPID-8657 > URL: https://issues.apache.org/jira/browse/QPID-8657 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-9.0.0 >Reporter: Kyrre >Priority: Minor > Attachments: aclRequest.json, qpidErrorLog.txt, resultingAcl.json > > > When POSTing an ACL rule with unknown attributes to the Qpid HTTP management > API, the server responds with HTTP 422, Unprocessable Entity. This is > somewhat OK, however, I think maybe a 400 Bad Request would be more > appropriate. > But after the post, the broker is somehow left in a bad internal state, as > the returned Json is incomplete and unparseable. > Example POST in [^aclRequest.json] > Qpid log from the incident [^qpidErrorLog.txt] > Returned Json from subsequent GET [^resultingAcl.json] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8657) ACL - Posting unknown attributes leaves broker in bad internal state
Kyrre created QPID-8657: --- Summary: ACL - Posting unknown attributes leaves broker in bad internal state Key: QPID-8657 URL: https://issues.apache.org/jira/browse/QPID-8657 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-9.0.0 Reporter: Kyrre Attachments: aclRequest.json, qpidErrorLog.txt, resultingAcl.json When POSTing an ACL rule with unknown attributes to the Qpid HTTP management API, the server responds with HTTP 422, Unprocessable Entity. This is somewhat OK, however, I think maybe a 400 Bad Request would be more appropriate. But after the post, the broker is somehow left in a bad internal state, as the returned Json is incomplete and unparseable. Example POST in [^aclRequest.json] Qpid log from the incident [^qpidErrorLog.txt] Returned Json from subsequent GET [^resultingAcl.json] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8656) Selector parsing logic error when combining NOT and LIKE
Kyrre created QPID-8656: --- Summary: Selector parsing logic error when combining NOT and LIKE Key: QPID-8656 URL: https://issues.apache.org/jira/browse/QPID-8656 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-9.0.0 Reporter: Kyrre The JMSSelectorFilter.match() gives unexpected results when combining the LIKE and NOT operators. The selector "NOT (entry LIKE '%aaa%')" and value "" returns true, as expected, The selector "NOT entry LIKE '%aaa%'" and value "" returns false, whcih is a bug. In both cases the method retuns true when the value is "" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8619) Easier ACL interface for REST management (JSON output?)
[ https://issues.apache.org/jira/browse/QPID-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681019#comment-17681019 ] Kyrre commented on QPID-8619: - Wow, thank you! I didn't know this endpoint existed. The broker book only contains examples of the extractRules endpoint, and hte API documentation is a bit terse, so I have missed this completely. Thank you for the clarification :) > Easier ACL interface for REST management (JSON output?) > --- > > Key: QPID-8619 > URL: https://issues.apache.org/jira/browse/QPID-8619 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-9.0.0 >Reporter: Kyrre >Priority: Minor > > We use the management interface over HTTPS to create queues and exchanges, as > well as managing ACLs to give and remove access to said queues and exchanges. > We have lots of extra code to parse ACLs from the management interface, which > is brittle and prone to braking. The ACLs are stored in the config.json as > JSON, and then transformed to a bespoke format returned to the client, which > then has to parse this format for manipulation. Would it not be much easier > to just return the JSON, which is a lot easier to parse? > If there's code/clients that require the bespoke format, maybe return JSON on > a parameter/request header? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8619) Easier ACL interface for REST management (JSON output?)
[
https://issues.apache.org/jira/browse/QPID-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680996#comment-17680996
]
Kyrre commented on QPID-8619:
-
Hi,
We use the url
"/api/latest/virtualhostaccesscontrolprovider/default//default/extractRules".
This gives us the ACL as documented at
[https://qpid.apache.org/releases/qpid-broker-j-9.0.0/book/Java-Broker-Security-AccessControlProviders.html]
As for the config.json, here's a snippet from our initial config:
{code:java}
"virtualhostaccesscontrolproviders": [
{
"name": "default",
"type": "RuleBased",
"defaultResult": "DENIED",
"rules": [
{
"objectType": "EXCHANGE",
"identity": "service-providers",
"operation": "PUBLISH",
"outcome": "ALLOW_LOG",
"attributes": {
"ROUTING_KEY": "onramp",
"NAME": ""
}
},
{
"objectType": "VIRTUALHOST",
"identity": "service-providers",
"operation": "ACCESS",
"outcome": "ALLOW_LOG",
"attributes": {
"NAME": "localhost"
}
},
{
"objectType": "VIRTUALHOST",
"identity": "clients-private-channels",
"operation": "ACCESS",
"outcome": "ALLOW_LOG",
"attributes": {
"NAME": "localhost"
}
},
{
"objectType": "QUEUE",
"identity": "ALL",
"operation": "CONSUME",
"outcome": "ALLOW_LOG",
"attributes": {
"NAME": "bi-queue"
}
},
{
"objectType": "ALL",
"identity": "ALL",
"operation": "ALL",
"outcome": "DENY_LOG",
"attributes": {}
}
]
}
] {code}
The config.json format is much easier for a client to parse, as it is a
well-known format.
> Easier ACL interface for REST management (JSON output?)
> ---
>
> Key: QPID-8619
> URL: https://issues.apache.org/jira/browse/QPID-8619
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-9.0.0
>Reporter: Kyrre
>Priority: Minor
>
> We use the management interface over HTTPS to create queues and exchanges, as
> well as managing ACLs to give and remove access to said queues and exchanges.
> We have lots of extra code to parse ACLs from the management interface, which
> is brittle and prone to braking. The ACLs are stored in the config.json as
> JSON, and then transformed to a bespoke format returned to the client, which
> then has to parse this format for manipulation. Would it not be much easier
> to just return the JSON, which is a lot easier to parse?
> If there's code/clients that require the bespoke format, maybe return JSON on
> a parameter/request header?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8619) Easier ACL interface for REST management (JSON output?)
Kyrre created QPID-8619: --- Summary: Easier ACL interface for REST management (JSON output?) Key: QPID-8619 URL: https://issues.apache.org/jira/browse/QPID-8619 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-9.0.0 Reporter: Kyrre We use the management interface over HTTPS to create queues and exchanges, as well as managing ACLs to give and remove access to said queues and exchanges. We have lots of extra code to parse ACLs from the management interface, which is brittle and prone to braking. The ACLs are stored in the config.json as JSON, and then transformed to a bespoke format returned to the client, which then has to parse this format for manipulation. Would it not be much easier to just return the JSON, which is a lot easier to parse? If there's code/clients that require the bespoke format, maybe return JSON on a parameter/request header? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8520) ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyrre updated QPID-8520:
Description:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly after these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null prevented
AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
Exception while notifying connection
PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
{quote}
>From the client side log:
{quote}org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://localhost:49201/api/latest/queue/default/localhost/":
Remote host terminated the handshake; nested exception is
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
{quote}
I am fully aware that this might be a bit too little to go by, but I have tried
in to create a reproducible code snippet, but cannot find a way to make the
error occur in a stable and reproducible way. I am also aware that this might
be caused by a number of other things, but figured thia would be a good start
to try to find out what to do about it.
was:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly aft these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null pr
[jira] [Updated] (QPID-8520) ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyrre updated QPID-8520:
Description:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly aft these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null prevented
AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
Exception while notifying connection
PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
{quote}
>From the client side log:
{quote}org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://localhost:49201/api/latest/queue/default/localhost/":
Remote host terminated the handshake; nested exception is
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
{quote}
I am fully aware that this might be a bit too little to go by, but I have tried
in to create a reproducible code snippet, but cannot find a way to make the
error occur in a stable and reproducible way. I am also aware that this might
be caused by a number of other things, but figured thia would be a good start
to try to find out what to do about it.
was:
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly after these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null pr
[jira] [Created] (QPID-8520) ReadPendingException thrown by Broker-J intermittently
Kyrre created QPID-8520:
---
Summary: ReadPendingException thrown by Broker-J intermittently
Key: QPID-8520
URL: https://issues.apache.org/jira/browse/QPID-8520
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-8.0.2
Environment: Broker-J 8.0.2
Spring Boot 3.2.2
Docker Engine v20.10.5
Testcontainers 1.15.1
Reporter: Kyrre
Our project is using the HTTPS management interface, using a REST client.
We've wrapped our qpid instance in a Docker container using testcontainers, and
have a test that sets up and tears down different elements we utilise in our
system with asserts that things are as we expected, all this over HTTPS between
the local machine and the container. This works splendidly, except for the fact
that we see intermittent errors in the test of the type
{quote}java.nio.channels.ReadPendingException: null
at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
at
org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
at
org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
at
org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
at
org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
at
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{quote}
This occurs directly after these log lines:
{quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116] (o.e.j.i.FillInterest)
- Read pending for null prevented
AC.ReadCB@108ec429\{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
Exception while notifying connection
PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
{quote}
>From the client side log:
{quote}org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://localhost:49201/api/latest/queue/default/localhost/":
Remote host terminated the handshake; nested exception is
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
{quote}
I am fully aware that this might be a bit too little to go by, but I have tried
in to create a reproducible code snippet, but cannot find a way to make the
error occur in a stable and reproducible way. I am also aware that this might
be caused by a number of other things, but figured thia would be a good start
to try to find out what to do about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
