[jira] [Updated] (PROTON-1737) Expose set/get for maxFrameSize in the Connection.Open performative
[ https://issues.apache.org/jira/browse/PROTON-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreeram Garlapati updated PROTON-1737: -- Affects Version/s: (was: proton-j-future) proton-j-0.24.0 > Expose set/get for maxFrameSize in the Connection.Open performative > --- > > Key: PROTON-1737 > URL: https://issues.apache.org/jira/browse/PROTON-1737 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Sreeram Garlapati >Priority: Minor > Fix For: proton-j-future > > > For Microsoft Azure EventHubs service - we need the below properties to > enable some of our scenarios: > Connection.setMaxFrameSize() & > Connection.getMaxFrameSize() -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1737) Expose set/get for maxFrameSize in the Connection.Open performative
[ https://issues.apache.org/jira/browse/PROTON-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreeram Garlapati updated PROTON-1737: -- Description: For Microsoft Azure EventHubs service - we need the below properties to enable some of our scenarios: Connection.setMaxFrameSize() & Connection.getMaxFrameSize() was:For Microsoft Azure EventHubs service - we need this setting to enable some of our scenarios - appreciate your help... > Expose set/get for maxFrameSize in the Connection.Open performative > --- > > Key: PROTON-1737 > URL: https://issues.apache.org/jira/browse/PROTON-1737 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-future >Reporter: Sreeram Garlapati >Priority: Minor > Fix For: proton-j-future > > > For Microsoft Azure EventHubs service - we need the below properties to > enable some of our scenarios: > Connection.setMaxFrameSize() & > Connection.getMaxFrameSize() -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1737) Expose set/get for maxFrameSize in the Connection.Open performative
Sreeram Garlapati created PROTON-1737: - Summary: Expose set/get for maxFrameSize in the Connection.Open performative Key: PROTON-1737 URL: https://issues.apache.org/jira/browse/PROTON-1737 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-future Reporter: Sreeram Garlapati Priority: Minor Fix For: proton-j-future For Microsoft Azure EventHubs service - we need this setting to enable some of our scenarios - appreciate your help... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317320#comment-16317320
]
Tim Taylor commented on PROTON-1718:
This seems to work perfectly for us. Any ETA on when this might be released?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317277#comment-16317277 ] ASF subversion and git services commented on QPID-6933: --- Commit ac146cdc8be593b39104d53a7517a594566b63ef in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ac146cd ] QPID-6933: [System Tests] Remove MultipleTransactedBatchProducerTest - test was added to demonstrate a Queue Runner specific defect > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton-j pull request #13: Added API to Transport interface to allow cu...
Github user timtay-microsoft closed the pull request at: https://github.com/apache/qpid-proton-j/pull/13 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316785#comment-16316785
]
Tim Taylor commented on PROTON-1718:
This looks perfect, I'll try testing it out today!
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316780#comment-16316780
]
Robbie Gemmell commented on PROTON-1718:
I have put in a change via PROTON-1736. It adds ability to set a listener on
the Sasl object, which is notified as frames arrive when the transport is
processed and can then be used to do related processing, such as selecting a
mechanism, responding to challenges, etc.
A 0.25.0 snapshot with the change is available in the snapshots repo
(https://repository.apache.org/content/repositories/snapshots/) if you want to
try it, or you can build the current master locally.
I put together this use of it within the reactor to show how it could be used
there:
{code}
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.Arrays;
import org.apache.qpid.proton.Proton;
import org.apache.qpid.proton.engine.BaseHandler;
import org.apache.qpid.proton.engine.Connection;
import org.apache.qpid.proton.engine.Event;
import org.apache.qpid.proton.engine.Sasl;
import org.apache.qpid.proton.engine.SaslListener;
import org.apache.qpid.proton.engine.Transport;
import org.apache.qpid.proton.reactor.Handshaker;
import org.apache.qpid.proton.reactor.Reactor;
import org.apache.qpid.proton.reactor.ReactorOptions;
public class ReactorSASL extends BaseHandler {
private final String host;
private final int port;
public static void main(String[] args) throws IOException {
ReactorOptions options = new ReactorOptions();
options.setEnableSaslByDefault(false);
Reactor reactor = Proton.reactor(options, new ReactorSASL("localhost",
5672));
reactor.run();
}
private ReactorSASL(String host, int port) {
this.host = host;
this.port = port;
}
@Override
public void onReactorInit(Event event) {
event.getReactor().connectionToHost(host, port, new
ReactorSASLHandler());
}
private static class ReactorSASLHandler extends BaseHandler {
private ReactorSASLHandler() {
// ..basic handshake handling..
add(new Handshaker());
}
@Override
public void onConnectionBound(Event e) {
Transport t = e.getTransport();
Sasl s = t.sasl();
s.client();
s.setListener(new SaslHandling());
}
@Override
public void onConnectionInit(Event event) {
Connection conn = event.getConnection();
conn.open();
}
@Override
public void onConnectionRemoteOpen(Event event) {
Connection conn = event.getConnection();
conn.close();
}
}
private static class SaslHandling implements SaslListener {
@Override
public void onSaslMechanisms(Sasl s, Transport t) {
// ...inspect remote offered mechs, select one and set any initial
response..
System.out.println("### mechs:" +
Arrays.toString(s.getRemoteMechanisms()));
s.setMechanisms("CUSTOM_MECH");
byte[] init = "initBytes".getBytes(StandardCharsets.UTF_8);
s.send(init, 0, init.length);
}
@Override
public void onSaslChallenge(Sasl s, Transport t) {
// ...process challenge, send response...
byte[] challenge = new byte[s.pending()];
s.recv(challenge, 0, challenge.length);
System.out.println("### challenged: " + new String(challenge,
StandardCharsets.UTF_8));
byte[] response = "responseBytes".getBytes(StandardCharsets.UTF_8);
s.send(response, 0, response.length);
}
@Override
public void onSaslOutcome(Sasl s, Transport t) {
System.out.println("### outcome:" + s.getOutcome());
}
@Override
public void onSaslInit(Sasl s, Transport t) { }
@Override
public void onSaslResponse(Sasl s, Transport t) { }
}
}
{code}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This
[jira] [Resolved] (PROTON-1736) add a SASL listener to allow relevant processing as frames arrive
[ https://issues.apache.org/jira/browse/PROTON-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1736. Resolution: Fixed > add a SASL listener to allow relevant processing as frames arrive > - > > Key: PROTON-1736 > URL: https://issues.apache.org/jira/browse/PROTON-1736 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-j-0.25.0 > > > The engine Sasl API in proton-j requires you be able to inspect its state to > decide what SASL handling to undertake and when while you are processing the > Transport. It would be helpful to be able to register a listener such that as > frames of interest arrive the relevant processing can be performed more > easily. This could simplify the Sasl object usage in general, but in > particular allow its use it with the 'reactor' where the IO handling being > generally hidden largely precludes using the API as intended. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1736) add a SASL listener to allow relevant processing as frames arrive
[ https://issues.apache.org/jira/browse/PROTON-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316752#comment-16316752 ] ASF subversion and git services commented on PROTON-1736: - Commit 17cef9ace9a7c75901d517f951ae1d4610819436 in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=17cef9a ] PROTON-1736: add a SASL listener to allow relevant processing as frames arrive > add a SASL listener to allow relevant processing as frames arrive > - > > Key: PROTON-1736 > URL: https://issues.apache.org/jira/browse/PROTON-1736 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-j-0.25.0 > > > The engine Sasl API in proton-j requires you be able to inspect its state to > decide what SASL handling to undertake and when while you are processing the > Transport. It would be helpful to be able to register a listener such that as > frames of interest arrive the relevant processing can be performed more > easily. This could simplify the Sasl object usage in general, but in > particular allow its use it with the 'reactor' where the IO handling being > generally hidden largely precludes using the API as intended. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1653) There seem to be C examples that are more probably tests
[ https://issues.apache.org/jira/browse/PROTON-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316733#comment-16316733 ] ASF subversion and git services commented on PROTON-1653: - Commit b95f752ab02edbf4cc21f08514b9e124c3738236 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b95f752 ] PROTON-1653: [C++ binding] Fix C++03 AND C++11 library builds - Really > There seem to be C examples that are more probably tests > > > Key: PROTON-1653 > URL: https://issues.apache.org/jira/browse/PROTON-1653 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher > > For example I'd say send-abort.c is a strange thing to have as an example as > it demonstrates a quite advanced protocol feature. > There are possibly others there also. > Not to say these aren't necessary for testing, just that they're not really > examples, perhaps in the tests area? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1736) add a SASL listener to allow relevant processing as frames arrive
Robbie Gemmell created PROTON-1736: -- Summary: add a SASL listener to allow relevant processing as frames arrive Key: PROTON-1736 URL: https://issues.apache.org/jira/browse/PROTON-1736 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.24.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: proton-j-0.25.0 The engine Sasl API in proton-j requires you be able to inspect its state to decide what SASL handling to undertake and when while you are processing the Transport. It would be helpful to be able to register a listener such that as frames of interest arrive the relevant processing can be performed more easily. This could simplify the Sasl object usage in general, but in particular allow its use it with the 'reactor' where the IO handling being generally hidden largely precludes using the API as intended. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")
[
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1733.
-
Resolution: Fixed
> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port()
> to get the actual listening port used by an open listener, for the case where
> the listener was started with port=0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")
[
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316583#comment-16316583
]
ASF subversion and git services commented on PROTON-1733:
-
Commit bfbc211ab76cc8a06414f34ffbcd0009a92ff686 in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bfbc211 ]
PROTON-1733: [cpp] fix tests/examples to check port in on_open
Some C++ tests/examples were checking the listening port before the on_open
event. This is incorrect and fails with the libuv proactor.
Also:
- added missing #include for atoi in listener.cpp
- updated reconnect_test.cpp to use binding to port 0
> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port()
> to get the actual listening port used by an open listener, for the case where
> the listener was started with port=0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8042) [Broker-J][AMQP 1.0] Add support for pipelined connection open containing sasl frames
[
https://issues.apache.org/jira/browse/QPID-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316512#comment-16316512
]
Keith Wall commented on QPID-8042:
--
The functional change looks reasonable but I am unhappy with the change to the
test made by 89e01ec. Given the work done by 2cbb629 those changes should not
be required. We need to understand why.
> [Broker-J][AMQP 1.0] Add support for pipelined connection open containing
> sasl frames
> -
>
> Key: QPID-8042
> URL: https://issues.apache.org/jira/browse/QPID-8042
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.1
>
>
> Opening of connection with pipelined SASL header, sasl mechanism frame (for
> plain), sasl init (with valid SASL initial response), protocol header and
> connection open frame fails with the following exception
> {noformat}
> org.apache.qpid.server.util.ConnectionScopedRuntimeException: Connection is
> closed before being fully established: specified frame size 1095586128 larger
> than maximum frame header size 4096
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.closeConnection(AMQPConnection_1_0Impl.java:1176)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.handleError(AMQPConnection_1_0Impl.java:783)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:215)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:570)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:361)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> As per spec section {{2.4.2 Pipelined Open}}
> {quote}
> For applications that use many short-lived connections, it MAY be desirable
> to pipeline the connection negotiation process. A peer MAY do this by
> starting to send subsequent frames before receiving the partner’s connection
> header or open frame. This is permitted so long as the pipelined frames are
> known a priori to conform to the
> capabilities and limitations of its partner.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8058) [Broker-J][AMQP 1.0] Broker does not respond to drain request from consumer of management temporary destination
[
https://issues.apache.org/jira/browse/QPID-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8058.
--
Resolution: Fixed
> [Broker-J][AMQP 1.0] Broker does not respond to drain request from consumer
> of management temporary destination
> ---
>
> Key: QPID-8058
> URL: https://issues.apache.org/jira/browse/QPID-8058
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testCreateQueueOnBrokerManagement.txt
>
>
> Test {{AmqpManagementTest.testCreateQueueOnBrokerManagement}} failed with the
> following error:
> {noformat}
> org.apache.qpid.jms.JmsOperationTimedOutException: Remote did not respond to
> a drain request in time
> {noformat}
> As per exception message, the client sent the Flow with drain=true but Broker
> did not reply on it
> {noformat}
> 2017-12-05 18:20:13,950 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> RECV[/127.0.0.1:48726|1] :
> Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=2,outgoingWindow=2147483647,handle=0,deliveryCount=0,linkCredit=1000,drain=true}
> {noformat}
> See the test log attached.
> Broker-J does not respond on flow performative with drain flag coming from
> consumers of temporary destinations created on management nodes ($management).
> Test attached receiver link for temporary destination created on management
> mode:
> {noformat}
> 2017-12-05 18:20:11,760 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> RECV[/127.0.0.1:48726|1] :
> Attach{name=qpid-jms:receiver:ID:0ea0fec9-455c-47db-b15e-4fd09c0c48d6:1:1:1:TempQueuecdf2fb78-beda-4456-9e2c-dd2dd4d9a53e,handle=0,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=TempQueuecdf2fb78-beda-4456-9e2c-dd2dd4d9a53e,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
> amqp:rejected:list, amqp:released:list,
> amqp:modified:list],capabilities=[temporary-queue]},target=Target{}}
> 2017-12-05 18:20:11,763 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> SEND[/127.0.0.1:48726|1] :
> Attach{name=qpid-jms:receiver:ID:0ea0fec9-455c-47db-b15e-4fd09c0c48d6:1:1:1:TempQueuecdf2fb78-beda-4456-9e2c-dd2dd4d9a53e,handle=0,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=TempQueuecdf2fb78-beda-4456-9e2c-dd2dd4d9a53e,durable=none,expiryPolicy=link-detach,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
> amqp:released:list,
> amqp:rejected:list],capabilities=[]},target=Target{},unsettled={},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
> {noformat}
> Granted credit
> {noformat}
> 2017-12-05 18:20:11,765 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> RECV[/127.0.0.1:48726|1] :
> Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=1,outgoingWindow=2147483647,handle=0,deliveryCount=0,linkCredit=1000}
> {noformat}
> Broker sent Transfer
> {noformat}
> 2017-12-05 18:20:13,949 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> SEND[/127.0.0.1:48726|1] :
> Transfer{handle=0,deliveryId=0,deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x00,messageFormat=0}
> {noformat}
> and immediately after transfer received Flow with drain=true
> {noformat}
> 2017-12-05 18:20:13,950 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame
> RECV[/127.0.0.1:48726|1] :
> Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=2,outgoingWindow=2147483647,handle=0,deliveryCount=0,linkCredit=1000,drain=true}
> {noformat}
> There was no message left on message source but broker did not send flow back.
> The existing implementation of {{ManagementNode#pullMessage}} does not notify
> its {{ConsumerTarget}} when there is no messages left to send.
> Only users of AMQP management are affected by the bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8060) [Broker-J] [AMQP 0-8..0-9-1] Declaring queue that specifies an alternate binding that does not exist crashes the Broker
[
https://issues.apache.org/jira/browse/QPID-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316470#comment-16316470
]
Keith Wall commented on QPID-8060:
--
Additional changes look okay to me, okay to port the functional changes to the
7.0.x branch.
> [Broker-J] [AMQP 0-8..0-9-1] Declaring queue that specifies an alternate
> binding that does not exist crashes the Broker
> ---
>
> Key: QPID-8060
> URL: https://issues.apache.org/jira/browse/QPID-8060
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.1
>
>
> Declaring queue with not existing alternate binding crashes the Broker with
> the following stack trace:
> {noformat}
> org.apache.qpid.server.configuration.IllegalConfigurationException: Cannot
> create alternate binding for 'test' : Alternate binding destination
> 'not_existing' cannot be found.
> at
> org.apache.qpid.server.queue.AbstractQueue.validateOrCreateAlternateBinding(AbstractQueue.java:3537)
> at
> org.apache.qpid.server.queue.AbstractQueue.onCreate(AbstractQueue.java:320)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doCreation(AbstractConfiguredObject.java:1273)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:893)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:866)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:865)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:75)
> at
> org.apache.qpid.server.queue.QueueFactory.createAsync(QueueFactory.java:58)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:145)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addChildAsync(AbstractConfiguredObject.java:2143)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.addChildAsync(AbstractVirtualHost.java:857)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2100)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2095)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
> at
> com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Client code:
> {code}
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
