[jira] [Updated] (DISPATCH-332) Heavy message loss happening with 2 interconnected routers
[ https://issues.apache.org/jira/browse/DISPATCH-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-332: --- Environment: Debian 8.3, Qpid Proton 0.12.2 for drivers and dependency for Qpid Dispatch, Hardware: 2 CPUs, 15 GB RAM, 30 GB HDD. (was: Debian 8.3, Qpid Proton 0.12.2 for drivers and dependency for Qpid Dispatch, Hardware: 2 CUPs, 15 GB RAM, 30 GB HDD.) > Heavy message loss happening with 2 interconnected routers > -- > > Key: DISPATCH-332 > URL: https://issues.apache.org/jira/browse/DISPATCH-332 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Qpid Proton 0.12.2 for drivers and > dependency for Qpid Dispatch, Hardware: 2 CPUs, 15 GB RAM, 30 GB HDD. >Reporter: Vishal Sharda >Priority: Blocker > > We are running two Dispatch Routers each configured for interior mode and the > second router's configuration includes a connector to the first router with > inter-router role. > When we connect one sender to one router and one receiver to the other router > both listening to the same queue, we see all messages (20,000 in our test) > being transmitted. > As soon as we start a second sender connected to the same router to which the > first sender connects and sending to the same queue, we start seeing heavy > message loss. Around 20% of messages are lost with each sender attempting to > send 20,000 messages on its own (40,000 in total) and running in parallel > with the other sender. The message loss happens regardless of the message > size. > We tried with simple_send.py, simple_recv.py as well as send and recv C > executable files from Qpid Proton 0.12.2. > We even saw a crash in the router with the following message: > qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Aborted > The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well > as the one taken on March 3 before the router core refactoring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279321#comment-15279321 ] Steven commented on QPID-7256: -- According to our business scene,We need that every time CeatConnection,Sending AMQP message、CloseConnection,These operations are in a loop. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[
https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279316#comment-15279316
]
Steven edited comment on QPID-7256 at 5/11/16 12:48 AM:
if I used the following code to test,it can send 1000 message successfully.
/*
*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*/
import java.io.InputStream;
import java.util.Properties;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* After change connection initial
* @author Steven
*/
public class Hello
{
private Connection connection;
private Context context;
private Session session;
public Context getContext() {
return context;
}
public void setContext(Context context) {
this.context = context;
}
public Session getSession() {
return session;
}
public void setSession(Session session) {
this.session = session;
}
public Connection getConnection() {
return connection;
}
public void setConnection(Connection connection) {
this.connection = connection;
}
public Hello()
{
}
public static void main(String[] args)
{
Hello hello = new Hello();
for(int i=0;i<1000;i++){
hello.runTest();
System.out.println("message "+i+" sent.");
}
hello.closeSession();
hello.closeConnection();
hello.closeContext();
}
private void runTest()
{
try (InputStream resourceAsStream =
this.getClass().getResourceAsStream("hello.properties"))
{
Properties properties = new Properties();
properties.load(resourceAsStream);
if(context == null){
context = new InitialContext(properties);
}else{
context = this.getContext();
}
ConnectionFactory connectionFactory = (ConnectionFactory)
context.lookup("qpidConnectionfactory");
if(connection == null){
connection = connectionFactory.createConnection();
}else{
connection = this.getConnection();
}
connection.start();
if(session == null){
session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
}else{
session = this.getSession();
}
Queue queue = (Queue) context.lookup("queue");
MessageProducer messageProducer = session.createProducer(queue);
TextMessage message = session.createTextMessage("Hello world!");
messageProducer.send(message);
}
catch (Exception exp)
{
exp.printStackTrace();
this.closeSession();
this.closeConnection();
this.closeContext();
}
}
private void closeConnection(){
try {
connection.close();
} catch (JMSException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
private void closeContext() {
try {
context.close();
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
private void closeSession(){
try {
session.close();
} catch (JMSException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
was (Author: stevengu):
if I used the following code to test,it can send 1000
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[
https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279316#comment-15279316
]
Steven commented on QPID-7256:
--
if I used the following code to test,it can send 1000 message successfully.
/*
*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*/
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.ExceptionListener;
import javax.jms.JMSException;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* After change connection initial and will throw exception sometimes
*
* @author Steven
*/
public class Hello_BeforeChange {
public Hello_BeforeChange() {
}
public static void main(String[] args) {
Hello_BeforeChange hello = new Hello_BeforeChange();
for (int i = 0; i < 1000; i++) {
hello.runTest();
System.out.println("message " + i + " sent.");
}
}
private Context getContext() {
Context context = null;
try {
InputStream resourceAsStream =
this.getClass().getResourceAsStream("hello.properties");
Properties properties = new Properties();
properties.load(resourceAsStream);
context = new InitialContext(properties);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return context;
}
private void runTest() {
Session session = null;
Connection connection = null;
Context context = null;
try {
context = this.getContext();
ConnectionFactory connectionFactory = (ConnectionFactory)
context.lookup("qpidConnectionfactory");
connection = connectionFactory.createConnection();
connection.setExceptionListener(new ExceptionListener()
{
@Override
public void onException(JMSException exception)
{
System.out.println("");
}
});
connection.start();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Queue queue = (Queue) context.lookup("queue");
MessageProducer messageProducer = session.createProducer(queue);
TextMessage message = session.createTextMessage("Hello world!");
messageProducer.send(message);
} catch (Exception exp) {
try {
if (session != null) {
session.close();
}
if (connection != null) {
connection.stop();
connection.close();
}
} catch (JMSException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
exp.printStackTrace();
}
}
}
> When invoke the method "connection.start" in a loop,reporting socket closed
> ---
>
> Key: QPID-7256
> URL: https://issues.apache.org/jira/browse/QPID-7256
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32
> Environment: windows7、 jdk7
>Reporter: Steven
>
> I use the for loop,It will loop 1000 times,every time,I create a
> connection,then send message,After the message has been sent,close the
> connection.
> this loop executed it for some times,It will report error,as you can see the
> screen shot
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279312#comment-15279312 ] Steven commented on QPID-7256: -- I was trying to connect to Qpid Java Broker. As you can see that I had a for loop,It can execute 1000 time,most of time,It can send message successfully,And It execute it for several times,It can report this error,So there is nothing with the username and password. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-332) Heavy message loss happening with 2 interconnected routers
[ https://issues.apache.org/jira/browse/DISPATCH-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-332: --- Description: We are running two Dispatch Routers each configured for interior mode and the second router's configuration includes a connector to the first router with inter-router role. When we connect one sender to one router and one receiver to the other router both listening to the same queue, we see all messages (20,000 in our test) being transmitted. As soon as we start a second sender connected to the same router to which the first sender connects and sending to the same queue, we start seeing heavy message loss. Around 20% of messages are lost with each sender attempting to send 20,000 messages on its own (40,000 in total) and running in parallel with the other sender. The message loss happens regardless of the message size. We tried with simple_send.py, simple_recv.py as well as send and recv C executable files from Qpid Proton 0.12.2. We even saw a crash in the router with the following message: qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well as the one taken on March 3 before the router core refactoring. was: We are running two Dispatch Routers each configured for interior mode and the second router's configuration includes a connector to the first router. When we connect one sender to one router and one receiver to the other router both listening to the same queue, we see all messages (20,000 in our test) being transmitted. As soon as we start a second sender connected to the same router to which the first sender connects and sending to the same queue, we start seeing heavy message loss. Around 20% of messages are lost with each sender attempting to send 20,000 messages on its own (40,000 in total) and running in parallel with the other sender. The message loss happens regardless of the message size. We tried with simple_send.py, simple_recv.py as well as send and recv C executable files from Qpid Proton 0.12.2. We even saw a crash in the router with the following message: qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well as the one taken on March 3 before the router core refactoring. > Heavy message loss happening with 2 interconnected routers > -- > > Key: DISPATCH-332 > URL: https://issues.apache.org/jira/browse/DISPATCH-332 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Qpid Proton 0.12.2 for drivers and > dependency for Qpid Dispatch, Hardware: 2 CUPs, 15 GB RAM, 30 GB HDD. >Reporter: Vishal Sharda >Priority: Blocker > > We are running two Dispatch Routers each configured for interior mode and the > second router's configuration includes a connector to the first router with > inter-router role. > When we connect one sender to one router and one receiver to the other router > both listening to the same queue, we see all messages (20,000 in our test) > being transmitted. > As soon as we start a second sender connected to the same router to which the > first sender connects and sending to the same queue, we start seeing heavy > message loss. Around 20% of messages are lost with each sender attempting to > send 20,000 messages on its own (40,000 in total) and running in parallel > with the other sender. The message loss happens regardless of the message > size. > We tried with simple_send.py, simple_recv.py as well as send and recv C > executable files from Qpid Proton 0.12.2. > We even saw a crash in the router with the following message: > qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Aborted > The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well > as the one taken on March 3 before the router core refactoring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-332) Heavy message loss happening with 2 interconnected routers
[ https://issues.apache.org/jira/browse/DISPATCH-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-332: --- Description: We are running two Dispatch Routers each configured for interior mode and the second router's configuration includes a connector to the first router. When we connect one sender to one router and one receiver to the other router both listening to the same queue, we see all messages (20,000 in our test) being transmitted. As soon as we start a second sender connected to the same router to which the first sender connects and sending to the same queue, we start seeing heavy message loss. Around 20% of messages are lost with each sender attempting to send 20,000 messages on its own (40,000 in total) and running in parallel with the other sender. The message loss happens regardless of the message size. We tried with simple_send.py, simple_recv.py as well as send and recv C executable files from Qpid Proton 0.12.2. We even saw a crash in the router with the following message: qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well as the one taken on March 3 before the router core refactoring. was: We are running two Dispatch Routers each configured for inter-router mode and the second router's configuration includes a connector to the first router. When we connect one sender to one router and one receiver to the other router both listening to the same queue, we see all messages (20,000 in our test) being transmitted. As soon as we start a second sender connected to the same router to which the first sender connects and sending to the same queue, we start seeing heavy message loss. Around 20% of messages are lost with each sender attempting to send 20,000 messages on its own (40,000 in total) and running in parallel with the other sender. The message loss happens regardless of the message size. We tried with simple_send.py, simple_recv.py as well as send and recv C executable files from Qpid Proton 0.12.2. We even saw a crash in the router with the following message: qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well as the one taken on March 3 before the router core refactoring. > Heavy message loss happening with 2 interconnected routers > -- > > Key: DISPATCH-332 > URL: https://issues.apache.org/jira/browse/DISPATCH-332 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Qpid Proton 0.12.2 for drivers and > dependency for Qpid Dispatch, Hardware: 2 CUPs, 15 GB RAM, 30 GB HDD. >Reporter: Vishal Sharda >Priority: Blocker > > We are running two Dispatch Routers each configured for interior mode and the > second router's configuration includes a connector to the first router. > When we connect one sender to one router and one receiver to the other router > both listening to the same queue, we see all messages (20,000 in our test) > being transmitted. > As soon as we start a second sender connected to the same router to which the > first sender connects and sending to the same queue, we start seeing heavy > message loss. Around 20% of messages are lost with each sender attempting to > send 20,000 messages on its own (40,000 in total) and running in parallel > with the other sender. The message loss happens regardless of the message > size. > We tried with simple_send.py, simple_recv.py as well as send and recv C > executable files from Qpid Proton 0.12.2. > We even saw a crash in the router with the following message: > qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Aborted > The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well > as the one taken on March 3 before the router core refactoring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-332) Heavy message loss happening with 2 interconnected routers
Vishal Sharda created DISPATCH-332: -- Summary: Heavy message loss happening with 2 interconnected routers Key: DISPATCH-332 URL: https://issues.apache.org/jira/browse/DISPATCH-332 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 0.6.0 Environment: Debian 8.3, Qpid Proton 0.12.2 for drivers and dependency for Qpid Dispatch, Hardware: 2 CUPs, 15 GB RAM, 30 GB HDD. Reporter: Vishal Sharda Priority: Blocker We are running two Dispatch Routers each configured for inter-router mode and the second router's configuration includes a connector to the first router. When we connect one sender to one router and one receiver to the other router both listening to the same queue, we see all messages (20,000 in our test) being transmitted. As soon as we start a second sender connected to the same router to which the first sender connects and sending to the same queue, we start seeing heavy message loss. Around 20% of messages are lost with each sender attempting to send 20,000 messages on its own (40,000 in total) and running in parallel with the other sender. The message loss happens regardless of the message size. We tried with simple_send.py, simple_recv.py as well as send and recv C executable files from Qpid Proton 0.12.2. We even saw a crash in the router with the following message: qdrouterd: /home/vsharda/qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted The message loss was observed with the 0.6.0 SNAPSHOT taken on May 9 as well as the one taken on March 3 before the router core refactoring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-173) Provide for finer grained control over automatic presettling of received messages
[ https://issues.apache.org/jira/browse/QPIDJMS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279135#comment-15279135 ] ASF subversion and git services commented on QPIDJMS-173: - Commit 895b3a826c55ab91a624f0ba44086f684c70f838 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=895b3a8 ] QPIDJMS-173 remove the presettle option for consumer in TX from the policy. > Provide for finer grained control over automatic presettling of received > messages > - > > Key: QPIDJMS-173 > URL: https://issues.apache.org/jira/browse/QPIDJMS-173 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Allow for configuration on a policy level for controlling automatic settling > of incoming messages. This make sense in cases such as Topic receivers etc > where the message loss is non-critical. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections
[ https://issues.apache.org/jira/browse/QPID-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reopened QPID-7215: -- > [Java Broker, WMC] WMC should use query to retrieve connections > --- > > Key: QPID-7215 > URL: https://issues.apache.org/jira/browse/QPID-7215 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch > > > currently the ManagedOperation getConnections on the VirtualHost returns the > connections and sessions with the full inherited context. > Now that we have queries we should use them for this purpose instead. > The ManagedOperation getConnections should be deprecated and removed in v7 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections
[
https://issues.apache.org/jira/browse/QPID-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279114#comment-15279114
]
Keith Wall commented on QPID-7215:
--
On trunk, if the last virtualhostnode is deleted, the WMC Broker tab stops
updating and the following Javascript error is seen in the Console. The same
problem does not happen on 6.0.x.
{noformat}
TypeError: undefined is not an object (evaluating
'that.brokerData.virtualhostnodes.length')
"http://localhost:8080/js/qpid/management/Broker.js:904:73
_4ec@http://localhost:8080/dojo/dojo/dojo.js:15:128311
_4e6@http://localhost:8080/dojo/dojo/dojo.js:15:128175
resolve@http://localhost:8080/dojo/dojo/dojo.js:15:129636
http://localhost:8080/dojo/dojo/promise/all.js:52:11
_4ec@http://localhost:8080/dojo/dojo/dojo.js:15:128311
_4e6@http://localhost:8080/dojo/dojo/dojo.js:15:128175
resolve@http://localhost:8080/dojo/dojo/dojo.js:15:129636
_4f2@http://localhost:8080/dojo/dojo/dojo.js:15:128920
_4ec@http://localhost:8080/dojo/dojo/dojo.js:15:128527
_4e6@http://localhost:8080/dojo/dojo/dojo.js:15:128175
resolve@http://localhost:8080/dojo/dojo/dojo.js:15:129636
_4f2@http://localhost:8080/dojo/dojo/dojo.js:15:128920
_4ec@http://localhost:8080/dojo/dojo/dojo.js:15:128592
{noformat}
> [Java Broker, WMC] WMC should use query to retrieve connections
> ---
>
> Key: QPID-7215
> URL: https://issues.apache.org/jira/browse/QPID-7215
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch
>
>
> currently the ManagedOperation getConnections on the VirtualHost returns the
> connections and sessions with the full inherited context.
> Now that we have queries we should use them for this purpose instead.
> The ManagedOperation getConnections should be deprecated and removed in v7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPIDJMS-173) Provide for finer grained control over automatic presettling of received messages
[ https://issues.apache.org/jira/browse/QPIDJMS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reopened QPIDJMS-173: -- Some additional cleanup todo here. > Provide for finer grained control over automatic presettling of received > messages > - > > Key: QPIDJMS-173 > URL: https://issues.apache.org/jira/browse/QPIDJMS-173 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Allow for configuration on a policy level for controlling automatic settling > of incoming messages. This make sense in cases such as Topic receivers etc > where the message loss is non-critical. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279077#comment-15279077
]
Keith Wall commented on QPID-7196:
--
Alex, can you review this commit please?
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:500)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:561)
> [classes/:na]
> at
>
[jira] [Assigned] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7196:
Assignee: Keith Wall (was: Alan Conway)
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:500)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:561)
> [classes/:na]
> at
>
[jira] [Updated] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7196:
-
Assignee: Alan Conway
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alan Conway
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:500)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:561)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:554)
> [classes/:na]
>
[jira] [Updated] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7196:
-
Assignee: Alex Rudyy (was: Keith Wall)
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:500)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:561)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:554)
>
[jira] [Updated] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7196:
-
Status: Reviewable (was: In Progress)
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:500)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:561)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:554)
>
[jira] [Commented] (QPID-7196) [Java Broker] ConcurrentModificationException can occur on Broker startup when virtual host is activated
[
https://issues.apache.org/jira/browse/QPID-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279070#comment-15279070
]
ASF subversion and git services commented on QPID-7196:
---
Commit 1743266 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1743266 ]
QPID-7196: [Java Broker] Derby - ensure system propery controlling the
redirection of derby logging is set early as possible by classloader
* system property now set as model is discovered rather than as Derby VHN or VH
is activated
> [Java Broker] ConcurrentModificationException can occur on Broker startup
> when virtual host is activated
>
>
> Key: QPID-7196
> URL: https://issues.apache.org/jira/browse/QPID-7196
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> ConcurrentModificationException is observed on broker start-up having 2
> virtual hosts with hundreds of queues. One host was DERBY VH and the other
> was BDB VH.
> {noformat}
> 2016-04-12 15:25:40,391 ERROR [VirtualHostNode-test-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'test'. Object will be put into ERROR state.
> java.util.ConcurrentModificationException: null
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> ~[na:1.8.0_66]
> at java.util.HashMap.putMapEntries(HashMap.java:511) ~[na:1.8.0_66]
> at java.util.HashMap.putAll(HashMap.java:784) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:2758)
> [classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBUtils.getCacheMode(BDBUtils.java:161)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getCacheMode(StandardEnvironmentFacadeFactory.java:66)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:110)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:82)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.berkeleydb.BDBMessageStore.openMessageStore(BDBMessageStore.java:80)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:1871)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1308)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1287)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:908)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:902)
> [classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
> [guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
> [guava-18.0.jar:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:901)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:80)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:513)
> [classes/:na]
> at
>
[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.
[ https://issues.apache.org/jira/browse/QPIDJMS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279017#comment-15279017 ] ASF subversion and git services commented on QPIDJMS-175: - Commit 0fe6b0471495821432f5e047c69287980edf6dac in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=0fe6b04 ] QPIDJMS-175 Use a more appropriate exception on the drain timeout. > Add support for a timeout value for drain requests. > --- > > Key: QPIDJMS-175 > URL: https://issues.apache.org/jira/browse/QPIDJMS-175 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add an additional timeout value in the AMQP consumer to deal with a remote > that doesn't respond to a drain request. The timeout handler should close > the MessageConsumer that is awaiting the drain with an exception since we > don't know what the remote state is following a lack of response to the > drain. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.
[ https://issues.apache.org/jira/browse/QPIDJMS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279016#comment-15279016 ] ASF subversion and git services commented on QPIDJMS-175: - Commit 1b05e92c2465620af07273c83cb0e15ee8833b8f in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=1b05e92 ] QPIDJMS-175 Add a test around drain timeout on transaction rollback with an initial change to allow the test to pass. > Add support for a timeout value for drain requests. > --- > > Key: QPIDJMS-175 > URL: https://issues.apache.org/jira/browse/QPIDJMS-175 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add an additional timeout value in the AMQP consumer to deal with a remote > that doesn't respond to a drain request. The timeout handler should close > the MessageConsumer that is awaiting the drain with an exception since we > don't know what the remote state is following a lack of response to the > drain. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279012#comment-15279012 ] Adel Boutros edited comment on DISPATCH-290 at 5/10/16 9:41 PM: This is the problem when working late, I start to get confused. You are right, you can ignore what i said about having to add it was (Author: adelbout...@live.com): This is the problem when working late, you start to get confused. You are right, you can ignore what i said about having to add it > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros >Assignee: Ted Ross > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279012#comment-15279012 ] Adel Boutros commented on DISPATCH-290: --- This is the problem when working late, you start to get confused. You are right, you can ignore what i said about having to add it > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros >Assignee: Ted Ross > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279005#comment-15279005 ] Ted Ross commented on DISPATCH-290: --- Sure. I interpreted your comment from the 25th as a request to remove that line from your patch. > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros >Assignee: Ted Ross > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6866) Paginate connections table on virtualhost tab
[ https://issues.apache.org/jira/browse/QPID-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6866: - Fix Version/s: qpid-java-6.1 > Paginate connections table on virtualhost tab > - > > Key: QPID-6866 > URL: https://issues.apache.org/jira/browse/QPID-6866 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1 > > > The connections table on the Virtualhost tab within the Web Management > Console is unpaginated. For use cases involving large numbers of > connections, this make the console harder to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6866) Paginate connections table on virtualhost tab
[ https://issues.apache.org/jira/browse/QPID-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-6866. -- Resolution: Fixed > Paginate connections table on virtualhost tab > - > > Key: QPID-6866 > URL: https://issues.apache.org/jira/browse/QPID-6866 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1 > > > The connections table on the Virtualhost tab within the Web Management > Console is unpaginated. For use cases involving large numbers of > connections, this make the console harder to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[
https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1527#comment-1527
]
Adel Boutros commented on DISPATCH-290:
---
[~tedross]
I noticed that in the code you submitted, you opted out the following line
{code}hints.ai_family = AF_UNSPEC;{code}.
Although it seems logical to assume that not specifying ai_family is equivalent
to *AF_UNSPEC* but on Solaris it is not the case. If you do not add that line,
it will still fail/hang on Solaris.
So can you please re-add it to the patch?
I had tested it before submitting the patch.
Regards,
Adel
> Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
> --
>
> Key: DISPATCH-290
> URL: https://issues.apache.org/jira/browse/DISPATCH-290
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Labels: build, solaris
> Fix For: 0.6.0
>
> Attachments:
> 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch,
> 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch,
> dispatch-290.patch
>
>
> Propose fixes so that qpid-dispatch can compile successfully on Solaris.
> - Add implicit dependencies explicitly
> - Replace linux specific options with generic options
> - Remove invalid options from CMakeLists.txt
> - Replace linux specific functions with generic functions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-290: - Assignee: Ted Ross > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros >Assignee: Ted Ross > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278853#comment-15278853 ] ASF subversion and git services commented on DISPATCH-290: -- Commit 4926d75aa1315731755fcf5bbc9a4f848083d5ae in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4926d75 ] DISPATCH-290 (Patch from Adel Boutros) - Updates to support the Solaris build > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-290. --- Resolution: Fixed > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-310) Use router.id instead of container.containerName
[ https://issues.apache.org/jira/browse/DISPATCH-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-310. --- Resolution: Fixed > Use router.id instead of container.containerName > > > Key: DISPATCH-310 > URL: https://issues.apache.org/jira/browse/DISPATCH-310 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.6.0 > > > DISPATCH-306 deprecated the container entity. The containerName is now the > router.id. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-310) Use router.id instead of container.containerName
[ https://issues.apache.org/jira/browse/DISPATCH-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278787#comment-15278787 ] ASF subversion and git services commented on DISPATCH-310: -- Commit 6422f523afd3378390c3bbb641a0f734ebe924d3 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6422f52 ] DISPATCH-310: Use router.id, router.routerId, or container.containerName respectively to match connection.container. > Use router.id instead of container.containerName > > > Key: DISPATCH-310 > URL: https://issues.apache.org/jira/browse/DISPATCH-310 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.6.0 > > > DISPATCH-306 deprecated the container entity. The containerName is now the > router.id. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-307) misc fixups for console plugin build
[ https://issues.apache.org/jira/browse/DISPATCH-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-307. --- Resolution: Fixed > misc fixups for console plugin build > > > Key: DISPATCH-307 > URL: https://issues.apache.org/jira/browse/DISPATCH-307 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 0.6.0 > > > The console plugin build needs some tweaks to fix some remaining issues, > around dependencies, compiler settings, project metadata needed for > deployment, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-307) misc fixups for console plugin build
[ https://issues.apache.org/jira/browse/DISPATCH-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278736#comment-15278736 ] ASF subversion and git services commented on DISPATCH-307: -- Commit c95bb8ae8849d5d040bfea582c94d5a1619d3949 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c95bb8a ] DISPATCH-307: Rename the artifact id to dispatch-hawtio-console for clarity > misc fixups for console plugin build > > > Key: DISPATCH-307 > URL: https://issues.apache.org/jira/browse/DISPATCH-307 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 0.6.0 > > > The console plugin build needs some tweaks to fix some remaining issues, > around dependencies, compiler settings, project metadata needed for > deployment, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Problems with setting up Qpid Java in Eclipse
Hi All, I have been trying to setup my dev environment for Qpid Java [1] using Eclipse and I have not been successful yet. Following are the approaches I tried so far: *1. Using Maven pom.xml to import projects* a) After getting the source, I do File -> Import -> Import Maven Project b) Select the root Qpid source directory (pom.xml is present here) c) Now I get eclipse pop up saying "No marketplace entries found to handle maven-antrun-plugin:1.7:run in Eclipse." d) I ignore that and hit Finish. Now almost all the projects has "Maven Project Build Lifecycle Mapping Problem" e) When I right click on the problem and select Quick Fix, I get the option to "Mark goal run as ignored" or "Permanently mark goal run in pom.xml as ignored". Not sure what is the right way here. *2. Using mvn eclipse:eclipse to generate project configurations* a) After getting source, I did mvn clean install -DskipTests (2 json related tests in systests are failing due to long path) mvn eclipse:eclipse b) mvn workspace generation fails, and after some reading I realized its not supported anymore. c) Now, I am able to import these projects using File -> Import -> General -> Existing Projects into Workspace and select root source directory. d) Now I get one project "qpid-java-build", and it has all the other projects as subfolder. Since its showing me everything (bin, target folders), I don't think the setup is correct. I am using Eclipse Mars.2. I also tried to use IntelliJ and there were no issues with it. However, since all the developers in my team use Eclipse, we need a way to figure out setting up the project in Eclipse. Any pointers are appreciated. Thanks Ramayan [1]. http://svn.apache.org/repos/asf/qpid/java/tags/6.0.2/
[jira] [Updated] (DISPATCH-330) Access control policy should return more suitable errors
[ https://issues.apache.org/jira/browse/DISPATCH-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-330: -- Assignee: Chuck Rolke > Access control policy should return more suitable errors > > > Key: DISPATCH-330 > URL: https://issues.apache.org/jira/browse/DISPATCH-330 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 0.6.0 >Reporter: Jakub Scholz >Assignee: Chuck Rolke > > Currently, if some action is denied by the access control policy, it always > returns amqp:resource-limit-exceeded error. This is fine when the deny was > issues because of a limit (e.g.number of connections, sessions etc.). > But when the action is denied for different reasons - e.g. because of > unallowed target / source, amqp:unauthorized-access would be much more > suitable than amqp:resource-limit-exceeded. As an example, see the situation > below. > Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 <- @attach(18) > [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", > handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, > source=@source(40) [address="request.ABCFR_ABCFRALMMACC1", durable=0, > timeout=0, dynamic=false], target=@target(41) > [address="request.ABCFR_ABCFRALMMACC1", durable=0, timeout=0, dynamic=false, > capabili > ties=:topic], initial-delivery-count=0] > Mon May 9 09:12:47 2016 POLICY (info) DENY AMQP Attach sender link > 'request.ABCFR_ABCFRALMMACC1' for user 'admin@QPID', host '127.0.0.1', app > '(null)' based on link target name > Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @attach(18) > [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", > handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0] > Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: > "\x00\x00\x00\x8f\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x7f\x00\x00\x00\x0a\xa1@request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1R\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00\x11\x00\x00\x00\x0b@R\x00@R\x00B@@\x00S)\xd0\x00\x00\x00\x0d\x00\x00\x00\x07@R\x00@R\x00BR\x00" > Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @detach(22) [handle=0, > closed=true, error=@error(29) [condition=:"amqp:resource-limit-exceeded", > description="link disallowed by local policy"]] > Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: > "\x00\x00\x00c\x02\x00\x00\x00\x00S\x16\xd0\x00\x00\x00S\x00\x00\x00\x03R\x00A\x00S\x1d\xd0\x00\x00\x00D\x00\x00\x00\x03\xa3\x1camqp:resource-limit-exceeded\xa1\x1flink > disallowed by local policy@" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-211) Expose connection properties in management response
[ https://issues.apache.org/jira/browse/DISPATCH-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-211: -- Fix Version/s: 0.7.0 > Expose connection properties in management response > --- > > Key: DISPATCH-211 > URL: https://issues.apache.org/jira/browse/DISPATCH-211 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.6.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > > The response for a management request for the .connection entity contains a > "properties" field, but it is always empty. > The connections properties should be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-103: -- Assignee: (was: Ted Ross) > Websocket Listeners > --- > > Key: DISPATCH-103 > URL: https://issues.apache.org/jira/browse/DISPATCH-103 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Priority: Minor > > Add an option in configured listeners to use websockets encapsulation. This > will allow AMQP clients inside web browsers to directly connect to the > message bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-331) Allow for a default policy to apply when open.hostname doesn't match an existing policy
Ted Ross created DISPATCH-331: - Summary: Allow for a default policy to apply when open.hostname doesn't match an existing policy Key: DISPATCH-331 URL: https://issues.apache.org/jira/browse/DISPATCH-331 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Chuck Rolke Fix For: 0.6.0 Add a feature to the policy engine that allows the deployer to specify a policy to be used for connections with no open.hostname or a hostname that does not match any existing policy. For users that don't wish to use open.hostname or any multi-tennancy feature, this default policy can be the only policy in effect for the network. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-306) Deprecate addr and routerId attributes in qdrouter schema and replace them with host and id respectively
[ https://issues.apache.org/jira/browse/DISPATCH-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278647#comment-15278647 ] Ernest Allen commented on DISPATCH-306: --- What I was seeing was because the config file I was using did not have a container section. When the config file has a container, the patch works as expected. > Deprecate addr and routerId attributes in qdrouter schema and replace them > with host and id respectively > > > Key: DISPATCH-306 > URL: https://issues.apache.org/jira/browse/DISPATCH-306 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.6.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > > Deprecate the addr attribute (of addrPort) and introduce host > Deprecate the routerId attribute of router entity and introduce id > The change must be backward compatible meaning that configs that use addr and > routerId must continue working after this change -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-47) qdrouterd doesn't know where its libraries are
[
https://issues.apache.org/jira/browse/DISPATCH-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-47.
--
Resolution: Fixed
Assignee: Ted Ross
Fix Version/s: 0.6.0
> qdrouterd doesn't know where its libraries are
> --
>
> Key: DISPATCH-47
> URL: https://issues.apache.org/jira/browse/DISPATCH-47
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Justin Ross
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> Install to prefix $HOME/local
> {noformat}
> jross@localhost sbin$ pwd
> /home/jross/local/sbin
> jross@localhost sbin$ ./qdrouterd
> ./qdrouterd: error while loading shared libraries: libqpid-dispatch.so.0:
> cannot open shared object file: No such file or directory
> jross@localhost sbin$ ls $HOME/local/lib64
> cmakelibqpid-dispatch.so.0libqpid-proton.so
> libqpid-proton.so.2.0.0 proton
> libqpid-dispatch.so libqpid-dispatch.so.0.1 libqpid-proton.so.2 pkgconfig
> {noformat}
> I can see how this might be the intended behavior, but it's not what I
> typically see for C projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-53) waypoints are not robust if targets not set up in advance.
[ https://issues.apache.org/jira/browse/DISPATCH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-53. -- Resolution: Fixed Assignee: Ted Ross Fix Version/s: 0.6.0 > waypoints are not robust if targets not set up in advance. > -- > > Key: DISPATCH-53 > URL: https://issues.apache.org/jira/browse/DISPATCH-53 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Reporter: Alan Conway >Assignee: Ted Ross >Priority: Minor > Fix For: 0.6.0 > > > When using a waypoint to route via an external broker queue (see > tests/system_tests_broker.py), you need to: > 1. start the broker and create the queue _before_ starting the router. > 2. wait for the router to establish a connection to the broker _before_ > sending messages. > We also need to consider the behavior if a waypoint is invalidated after it > has been in use, either by the connection dropping or the broker queue being > deleted. > We could hold messages up to some time/space limit in the hope that the > waypoint will be (re-)activated, or we can just drop them. It would be good > to be able to notify the sender but currently we don't have a way to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-58) Router/Broker interaction - Unroutable/released messages are continually resent
[ https://issues.apache.org/jira/browse/DISPATCH-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-58. -- Resolution: Fixed Fix Version/s: 0.6.0 > Router/Broker interaction - Unroutable/released messages are continually > resent > --- > > Key: DISPATCH-58 > URL: https://issues.apache.org/jira/browse/DISPATCH-58 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.2 >Reporter: Ted Ross >Assignee: Ken Giusti > Fix For: 0.6.0 > > > There's an issue with the fact that the router releases unroutable messages. > When the message originates from a broker, that broker will continually > re-send the message, burning network bandwidth, until the message becomes > routable. > Here are a few ideas as to how to address this situation: > - Have the ingress router hold the message for a time if it is not routable > to avoid rapidly releasing. > - Introduce a notion of not-routable-now vs. not-routable-ever. This would > allow the router to hold-for-retry or immediately reject. > Are there cases where the current behavior is desirable? If the producer > node has multiple outgoing links, a quick release would allow it to use an > alternate link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-175) Router continues to forward messages to the broker even when the broker is not available
[ https://issues.apache.org/jira/browse/DISPATCH-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-175. --- Resolution: Fixed Assignee: Ted Ross Fix Version/s: 0.6.0 > Router continues to forward messages to the broker even when the broker is > not available > > > Key: DISPATCH-175 > URL: https://issues.apache.org/jira/browse/DISPATCH-175 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.5 > Environment: Red Hat >Reporter: linuxta >Assignee: Ted Ross > Fix For: 0.6.0 > > > Config router to connect to a single broker. > When the broker is down, the router continues to forward messages received > from clients to the broker. This causes message loss. > Log looks like this: > SERVER (trace) Connection to (broker ip) failed > SERVER (trace) Connecting to (broker ip) > SERVER (trace) Connecting to (broker ip) > ... > MESSAGE (trace) Receiving Message ... > MESSAGE (trace) Sending Message ... > SERVER (trace) Connecting to (broker ip) > Should proton clients get some kind of error? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-176) Messages sent got lost when one of the brokers went down
[
https://issues.apache.org/jira/browse/DISPATCH-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-176.
---
Resolution: Fixed
Assignee: Ted Ross
Fix Version/s: 0.6.0
> Messages sent got lost when one of the brokers went down
> -
>
> Key: DISPATCH-176
> URL: https://issues.apache.org/jira/browse/DISPATCH-176
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.5
> Environment: Red Hat
>Reporter: linuxta
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> Config router to connect to two brokers.
> - A python client sends messages to the router. Another python client
> connects to the two brokers directly to receive messages.
> - Shutdown one of the brokers while the sender is sending messages to the
> router.
> Result: Some messages got lost. The sender did not get confirmation for all
> messages sent. The receiver did not get those messages either.
> router config used:
> listener
> { addr: 0.0.0.0 port: amqp sasl-mechanisms: ANONYMOUS }
> connector
> { name: broker1 role: on-demand addr: ... port: ... sasl-mechanisms:
> ANONYMOUS }
> connector
> { name: broker2 role: on-demand addr: ... port: ... sasl-mechanisms:
> ANONYMOUS }
> router
> { mode:standalone router-id: LB_R1 }
> waypoint
> { address: user.bar out-phase: 1 in-phase: 0 connector: broker1 }
> waypoint
> { address: user.bar out-phase: 1 in-phase: 0 connector: broker2 }
> fixed-address
> { prefix: /user phase: 0 fanout: single bias: spread }
> fixed-address
> { prefix: /user phase: 1 fanout: single bias: closest }
> log
> { module: ROUTER enable: trace+ }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-207) When a message body of [ ] is sent from rhea it is rejected as an invalid body
[ https://issues.apache.org/jira/browse/DISPATCH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-207. --- Resolution: Fixed Assignee: Ganesh Murthy Fix Version/s: 0.6.0 > When a message body of [ ] is sent from rhea it is rejected as an invalid > body > --- > > Key: DISPATCH-207 > URL: https://issues.apache.org/jira/browse/DISPATCH-207 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.5 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > > When using rhea to send a management GET-SCHEMA request, a message body of [ > ] is expected. > However, an error is raised: ERROR (error) Invalid message: Invalid body value > I originally thought this was raising an exception and the router was > becoming unresponsive, but I can't reproduce that behavior. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-234) undeliverable-here set to true for messages from waypoints if there is no receiver
[ https://issues.apache.org/jira/browse/DISPATCH-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-234. --- Resolution: Fixed Fix Version/s: 0.6.0 The 0.6.0 architecture update removes this behavior. > undeliverable-here set to true for messages from waypoints if there is no > receiver > -- > > Key: DISPATCH-234 > URL: https://issues.apache.org/jira/browse/DISPATCH-234 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.5 >Reporter: Gordon Sim > Fix For: 0.6.0 > > > After a receiver has been active (but once it has disconnected), messages > continue to flow from a waypoint to the router. The router sends a > disposition for these of MODIFIED with undeliverable-here set to true. The > undeliverable-here flag prevents the waypoint (qpidd in my case) from > delivering the messages again over the current link (and in qpidd's case it > actually treats it as a reject). > This means that you don't have proper queueing with waypoints in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-306) Deprecate addr and routerId attributes in qdrouter schema and replace them with host and id respectively
[ https://issues.apache.org/jira/browse/DISPATCH-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-306: -- Fix Version/s: 0.6.0 > Deprecate addr and routerId attributes in qdrouter schema and replace them > with host and id respectively > > > Key: DISPATCH-306 > URL: https://issues.apache.org/jira/browse/DISPATCH-306 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.6.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > > Deprecate the addr attribute (of addrPort) and introduce host > Deprecate the routerId attribute of router entity and introduce id > The change must be backward compatible meaning that configs that use addr and > routerId must continue working after this change -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-310) Use router.id instead of container.containerName
[ https://issues.apache.org/jira/browse/DISPATCH-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-310: -- Fix Version/s: 0.6.0 > Use router.id instead of container.containerName > > > Key: DISPATCH-310 > URL: https://issues.apache.org/jira/browse/DISPATCH-310 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.6.0 > > > DISPATCH-306 deprecated the container entity. The containerName is now the > router.id. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-290) Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-290: -- Fix Version/s: 0.6.0 > Adapt CMakeLists.txt and code so that qpid-dispatch can be compiled on Solaris > -- > > Key: DISPATCH-290 > URL: https://issues.apache.org/jira/browse/DISPATCH-290 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Adel Boutros > Labels: build, solaris > Fix For: 0.6.0 > > Attachments: > 0001-Add-hints-on-when-using-getaddrinfo-to-have-successf.patch, > 0001-Fixing-cmake-files-to-compile.-Fixing-OS-related-lib.patch, > dispatch-290.patch > > > Propose fixes so that qpid-dispatch can compile successfully on Solaris. > - Add implicit dependencies explicitly > - Replace linux specific options with generic options > - Remove invalid options from CMakeLists.txt > - Replace linux specific functions with generic functions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-320) SSL enabled connector does not do hostname verification
[ https://issues.apache.org/jira/browse/DISPATCH-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-320: -- Fix Version/s: 0.6.0 > SSL enabled connector does not do hostname verification > --- > > Key: DISPATCH-320 > URL: https://issues.apache.org/jira/browse/DISPATCH-320 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.6.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > > When a connector is ssl enabled (contains an sslProfile), dispatch does not > do hostname verification. > Dispatch must ensure that the host name in the URL to which it connects > matches the host name in the digital certificate that the server sends back > as part of the SSL connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1181) [reactor] Use the host passed to pn_reactor_connection_to_host as default hostname for open frame
[ https://issues.apache.org/jira/browse/PROTON-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed PROTON-1181. -- Resolution: Won't Fix It is not proper to meld the TCP host address with the AMQP 1.0 Connection Open hostname. The hostname in the Open performative is the virtual host, which is distinct from the TCP host address. > [reactor] Use the host passed to pn_reactor_connection_to_host as default > hostname for open frame > - > > Key: PROTON-1181 > URL: https://issues.apache.org/jira/browse/PROTON-1181 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j, python-binding >Affects Versions: 0.13.0 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.13.0 > > > Modify the 'connection_to_host' reactor interface to use the passed host > parameter as the default for the connection's hostname sent in the open frame. > This should only be done if the host parameter is NOT a numerical IP address > (do it for DNS-like names). > Modify the pn_connection_set_hostname() to take a NULL argument so the > default can be reset (e.g. no hostname in open frame). > The default can be overridden by setting the desired hostname via the > connection's set_hostname method. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1172) Bump the priority of reactor 'connecting' log messages down to Debug
[
https://issues.apache.org/jira/browse/PROTON-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278441#comment-15278441
]
ASF subversion and git services commented on PROTON-1172:
-
Commit 12ebe05a4c1392fd77f4cd48ef70100f10a09e5c in qpid-proton's branch
refs/heads/master from [~kgiusti]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=12ebe05 ]
PROTON-1172: bump down the severity of reactor connection events
> Bump the priority of reactor 'connecting' log messages down to Debug
>
>
> Key: PROTON-1172
> URL: https://issues.apache.org/jira/browse/PROTON-1172
> Project: Qpid Proton
> Issue Type: Wish
> Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
> Fix For: 0.13.0
>
>
> The log messages:
> ./proton/reactor.py:541:logging.info("connecting to %s..." % url)
> ./proton/reactor.py:570:logging.info("connected to %s" %
> event.connection.hostname)
> should probably be bumped down to debug. The less chatty a utility module
> like Reactor is the better. We should reserve >= INFO for less routine
> events.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1172) Bump the priority of reactor 'connecting' log messages down to Debug
[
https://issues.apache.org/jira/browse/PROTON-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-1172.
Resolution: Fixed
> Bump the priority of reactor 'connecting' log messages down to Debug
>
>
> Key: PROTON-1172
> URL: https://issues.apache.org/jira/browse/PROTON-1172
> Project: Qpid Proton
> Issue Type: Wish
> Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
> Fix For: 0.13.0
>
>
> The log messages:
> ./proton/reactor.py:541:logging.info("connecting to %s..." % url)
> ./proton/reactor.py:570:logging.info("connected to %s" %
> event.connection.hostname)
> should probably be bumped down to debug. The less chatty a utility module
> like Reactor is the better. We should reserve >= INFO for less routine
> events.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5816) [Java Client 0-10] If a resolved destination is used to create a consumer on a new connection created after destination was resolved, the client does not try to create t
[
https://issues.apache.org/jira/browse/QPID-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278418#comment-15278418
]
ASF subversion and git services commented on QPID-5816:
---
Commit 1743228 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1743228 ]
QPID-5816: [Java Client] Maintain a per-session (weak) cache of resolved
Destinations
> [Java Client 0-10] If a resolved destination is used to create a consumer on
> a new connection created after destination was resolved, the client does not
> try to create the destination on the broker
> -
>
> Key: QPID-5816
> URL: https://issues.apache.org/jira/browse/QPID-5816
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.20, 0.22, 0.24, 0.26
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.0.3
>
>
> On consumer creation for a destination marked as resolved 0.10 client does
> not send exchange.declare, queue.declare and exchange.bind commands to the
> broker in order to create the corresponding broker entities.
> If such resolved destination is used to create consumer and the destination
> node does not exist on a broker, the consumer creation will fail.
> In response to subscribe command the broker can return an exception because
> destination does not exist:
> {noformat}
> ...
> SEND: [conn:7e779b1b] ch=0 id=2 MessageSubscribe(queue=test_queue,
> destination=1, acceptMode=EXPLICIT, acquireMode=PRE_ACQUIRED, resumeTtl=0,
> arguments={x-filter-jms-selector=})
> ...
> RECV: [conn:7e779b1b] ch=0 ExecutionException(errorCode=NOT_FOUND,
> commandId=2, description=Queue: test_queue not found)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1172) Bump the priority of reactor 'connecting' log messages down to Debug
[
https://issues.apache.org/jira/browse/PROTON-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned PROTON-1172:
--
Assignee: Ken Giusti
> Bump the priority of reactor 'connecting' log messages down to Debug
>
>
> Key: PROTON-1172
> URL: https://issues.apache.org/jira/browse/PROTON-1172
> Project: Qpid Proton
> Issue Type: Wish
> Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
> Fix For: 0.13.0
>
>
> The log messages:
> ./proton/reactor.py:541:logging.info("connecting to %s..." % url)
> ./proton/reactor.py:570:logging.info("connected to %s" %
> event.connection.hostname)
> should probably be bumped down to debug. The less chatty a utility module
> like Reactor is the better. We should reserve >= INFO for less routine
> events.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1193) Proton-c uses getaddrinfo/socket calls incorrectly
[ https://issues.apache.org/jira/browse/PROTON-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1193. - Resolution: Fixed Fix Version/s: 0.13.0 > Proton-c uses getaddrinfo/socket calls incorrectly > -- > > Key: PROTON-1193 > URL: https://issues.apache.org/jira/browse/PROTON-1193 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: freebsd > Fix For: 0.13.0 > > > This problem was discovered testing on freebsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1193) Proton-c uses getaddrinfo/socket calls incorrectly
[ https://issues.apache.org/jira/browse/PROTON-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278166#comment-15278166 ] ASF subversion and git services commented on PROTON-1193: - Commit b9e60cd6c8f3aa3176aca4aa34a7059b902c91bc in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b9e60cd ] PROTON-1193: Incorrect use of getaddrinfo/socket calls - Because of inconsistent use of getaddrinfo and socket calls it was possible to attempt to create socket types that are not valid - Detected on FreeBSD > Proton-c uses getaddrinfo/socket calls incorrectly > -- > > Key: PROTON-1193 > URL: https://issues.apache.org/jira/browse/PROTON-1193 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: freebsd > > This problem was discovered testing on freebsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1193) Proton-c uses getaddrinfo/socket calls incorrectly
[ https://issues.apache.org/jira/browse/PROTON-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1193: --- Assignee: Andrew Stitcher > Proton-c uses getaddrinfo/socket calls incorrectly > -- > > Key: PROTON-1193 > URL: https://issues.apache.org/jira/browse/PROTON-1193 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: freebsd > > This problem was discovered testing on freebsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1193) Proton-c uses getaddrinfo/socket calls incorrectly
Andrew Stitcher created PROTON-1193: --- Summary: Proton-c uses getaddrinfo/socket calls incorrectly Key: PROTON-1193 URL: https://issues.apache.org/jira/browse/PROTON-1193 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.12.0 Reporter: Andrew Stitcher This problem was discovered testing on freebsd -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-321.
Resolution: Fixed
Fix Version/s: 0.6.0
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278103#comment-15278103
]
ASF GitHub Bot commented on DISPATCH-321:
-
Github user asfgit closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/71
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278102#comment-15278102
]
ASF subversion and git services commented on DISPATCH-321:
--
Commit e9f1dd4951970ff6110229614f312ee5809979ec in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e9f1dd4 ]
DISPATCH-321 - Removed qdpn_connector_close call from process_connector. This
will prevent premature closing of connection
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-321 - Removed qdpn_connector_...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/71 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7251) [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
[
https://issues.apache.org/jira/browse/QPID-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278043#comment-15278043
]
ASF subversion and git services commented on QPID-7251:
---
Commit 1743168 from [~lorenz.quack] in branch 'qpid/trunk'
[ https://svn.apache.org/r1743168 ]
QPID-7251: [Python Client] fix explicit setting of mechanism and/or response on
AMQP 0-8 and 0-9
> [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then
> PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
> --
>
> Key: QPID-7251
> URL: https://issues.apache.org/jira/browse/QPID-7251
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Reporter: Alex Rudyy
>Assignee: Lorenz Quack
>
> Before adding the ability to negotiate SASL mechanism (in QPID-6116) the
> required mechanism could be specified with parameter 'mechanism' in
> Client.start(...). The client still support this parameter but sasl object is
> not created and receipt of connection.start results in error as the one below:
> {noformat}
> Error in handler: connection_start
> Traceback (most recent call last):
> File "/home/alex/qpid/python/qpid/delegate.py", line 47, in __call__
> return handler(channel, frame)
> File "/home/alex/qpid/python/qpid/client.py", line 167, in connection_start
> self.client.response = self.client.sasl.initialResponse()
> AttributeError: 'NoneType' object has no attribute 'initialResponse'
> {noformat}
> In general, it is not good idea to specify the mechanism explicitly. The
> client application should rely on existing negotiation logic. However, the
> client should keep backward compatibility and should respect the provided
> mechanism: at least it can check whether mechanism is supported by the broker
> and create sasl object to drive sasl negotiation if mechanism is supported;
> otherwise, throw sasl exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.
[ https://issues.apache.org/jira/browse/QPIDJMS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277994#comment-15277994 ] ASF subversion and git services commented on QPIDJMS-175: - Commit 590b3c65dae57bd0f21050ef13674121b4bf9766 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=590b3c6 ] QPIDJMS-175: use the method to do the lookup as the preceding check did > Add support for a timeout value for drain requests. > --- > > Key: QPIDJMS-175 > URL: https://issues.apache.org/jira/browse/QPIDJMS-175 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add an additional timeout value in the AMQP consumer to deal with a remote > that doesn't respond to a drain request. The timeout handler should close > the MessageConsumer that is awaiting the drain with an exception since we > don't know what the remote state is following a lack of response to the > drain. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7257) [Java Broker] Correct connection state logging
[ https://issues.apache.org/jira/browse/QPID-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277993#comment-15277993 ] ASF subversion and git services commented on QPID-7257: --- Commit 1743161 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1743161 ] QPID-7257: [Java Broker] Correct connection state logging > [Java Broker] Correct connection state logging > -- > > Key: QPID-7257 > URL: https://issues.apache.org/jira/browse/QPID-7257 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > > Correct connection state logging -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7257) [Java Broker] Correct connection state logging
Alex Rudyy created QPID-7257: Summary: [Java Broker] Correct connection state logging Key: QPID-7257 URL: https://issues.apache.org/jira/browse/QPID-7257 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Alex Rudyy Fix For: qpid-java-6.0.3, qpid-java-6.1 Correct connection state logging -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[
https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277934#comment-15277934
]
Rob Godfrey commented on QPID-7256:
---
Which broker/service are you trying to connect to (e.g. Qpid Java Broker, Qpid
C++ Broker, ActiveMQ, Microsoft Azure Service Bus, etc)?
The exception is suggesting a failure to authenticate
{quote}
javax.jms.JMSSecurityException: Failed to authenticate user[admin].
at
org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:188)
{quote}
Are there logs from the broker/service you are connecting to that explain the
nature of the authentication failure?
Note that the ExceptionListener is not called for exceptions which are
communicated synchronously to the application - such as the one thrown on
connection.start();
> When invoke the method "connection.start" in a loop,reporting socket closed
> ---
>
> Key: QPID-7256
> URL: https://issues.apache.org/jira/browse/QPID-7256
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32
> Environment: windows7、 jdk7
>Reporter: Steven
>
> I use the for loop,It will loop 1000 times,every time,I create a
> connection,then send message,After the message has been sent,close the
> connection.
> this loop executed it for some times,It will report error,as you can see the
> screen shot
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277912#comment-15277912 ] Steven commented on QPID-7256: -- originally,I want to use the method "connection.setExceptionListener(new ExceptionListener()" 's callback method,When the connection is closed,The ExceptionListener() can be invoked,In this method,I want to reconnect it,But I set the breakpoint,Then I debug the code,When the socket closed is happened,It cannot enter the breakpoint. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277897#comment-15277897 ] Steven edited comment on QPID-7256 at 5/10/16 10:11 AM: after it had executed it for some time,It will report socket closed,when invoking connection.start(); essage 40 sent. message 41 sent. message 42 sent. message 43 sent. message 44 sent. message 45 sent. message 46 sent. message 47 sent. java.net.SocketException: Socket Closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.net.SocketInputStream.read(SocketInputStream.java:108) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.doRead(TCPTransportProvider.java:234) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.access$000(TCPTransportProvider.java:47) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider$1.run(TCPTransportProvider.java:185) at java.lang.Thread.run(Thread.java:745) javax.jms.JMSSecurityException: Failed to authenticate user[admin]. at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:188) at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.start(ConnectionImpl.java:365) at Hello_BeforeChange.runTest(Hello_BeforeChange.java:94) at Hello_BeforeChange.main(Hello_BeforeChange.java:51) message 48 sent. message 49 sent. message 50 sent. message 51 sent. message 52 sent. message 53 sent. Could you help me look at this issue?Thanks in Avance was (Author: stevengu): after it had executed it for some time,It will report socket closed,when invoking connection.start(); essage 40 sent. message 41 sent. message 42 sent. message 43 sent. message 44 sent. message 45 sent. message 46 sent. message 47 sent. java.net.SocketException: Socket Closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.net.SocketInputStream.read(SocketInputStream.java:108) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.doRead(TCPTransportProvider.java:234) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.access$000(TCPTransportProvider.java:47) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider$1.run(TCPTransportProvider.java:185) at java.lang.Thread.run(Thread.java:745) javax.jms.JMSSecurityException: Failed to authenticate user[admin]. at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:188) at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.start(ConnectionImpl.java:365) at Hello_BeforeChange.runTest(Hello_BeforeChange.java:94) at Hello_BeforeChange.main(Hello_BeforeChange.java:51) message 48 sent. message 49 sent. message 50 sent. message 51 sent. message 52 sent. message 53 sent. Could you help me look at this issue?Thanks in Avance > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277897#comment-15277897 ] Steven edited comment on QPID-7256 at 5/10/16 10:11 AM: after it had executed it for some time,It will report socket closed,when invoking connection.start(); essage 40 sent. message 41 sent. message 42 sent. message 43 sent. message 44 sent. message 45 sent. message 46 sent. message 47 sent. java.net.SocketException: Socket Closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.net.SocketInputStream.read(SocketInputStream.java:108) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.doRead(TCPTransportProvider.java:234) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.access$000(TCPTransportProvider.java:47) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider$1.run(TCPTransportProvider.java:185) at java.lang.Thread.run(Thread.java:745) javax.jms.JMSSecurityException: Failed to authenticate user[admin]. at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:188) at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.start(ConnectionImpl.java:365) at Hello_BeforeChange.runTest(Hello_BeforeChange.java:94) at Hello_BeforeChange.main(Hello_BeforeChange.java:51) message 48 sent. message 49 sent. message 50 sent. message 51 sent. message 52 sent. message 53 sent. Could you help me look at this issue?Thanks in Avance was (Author: stevengu): after it had executed it for some time,It will report socket closed,when invoking connection.start(); essage 40 sent. message 41 sent. message 42 sent. message 43 sent. message 44 sent. message 45 sent. message 46 sent. message 47 sent. java.net.SocketException: Socket Closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.net.SocketInputStream.read(SocketInputStream.java:108) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.doRead(TCPTransportProvider.java:234) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider.access$000(TCPTransportProvider.java:47) at org.apache.qpid.amqp_1_0.client.TCPTransportProvider$1.run(TCPTransportProvider.java:185) at java.lang.Thread.run(Thread.java:745) javax.jms.JMSSecurityException: Failed to authenticate user[admin]. at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.connect(ConnectionImpl.java:188) at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.start(ConnectionImpl.java:365) at Hello_BeforeChange.runTest(Hello_BeforeChange.java:94) at Hello_BeforeChange.main(Hello_BeforeChange.java:51) message 48 sent. message 49 sent. message 50 sent. message 51 sent. message 52 sent. message 53 sent. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
Steven created QPID-7256: Summary: When invoke the method "connection.start" in a loop,reporting socket closed Key: QPID-7256 URL: https://issues.apache.org/jira/browse/QPID-7256 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.32 Environment: windows7、 jdk7 Reporter: Steven I use the for loop,It will loop 1000 times,every time,I create a connection,then send message,After the message has been sent,close the connection. this loop executed it for some times,It will report error,as you can see the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7253) [Java Client 0-10] Application allowed to create new JMS session whilst failover is in progress
[
https://issues.apache.org/jira/browse/QPID-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277856#comment-15277856
]
Alex Rudyy commented on QPID-7253:
--
The changes look reasonable to me. We should port them into 6.0.x branch
> [Java Client 0-10] Application allowed to create new JMS session whilst
> failover is in progress
> ---
>
> Key: QPID-7253
> URL: https://issues.apache.org/jira/browse/QPID-7253
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.2
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.3, qpid-java-6.1
>
>
> Unlike the 0-8 path, creating a JMS session {{Connection#createSession()}}
> does not take the failover mutex. This means that an application's call to
> createSession does not block whilst failover is in flight. This gives rise
> to a race between application's creation of the new session and the
> re-subscription of the existing sessions. In an unlucky case, this may cause
> the client to try and attach the same session twice. This will be rejected
> by the Broker with a SESSION_BUSY.
> Following annotated log excerpt is from 6.0.2.
> {noformat}
> # Failover has just reconnected an application with existing JMS sessions,
> but failover is not yet 'finished'
> 2016-05-04 17:31:26,778 DEBUG [com/192.168.0.1:18575] [
>Connection] RECV: [conn:eb35720] ch=0 ConnectionOpenOk(knownHosts=[])
> 2016-05-04 17:31:26,779 INFO [com/192.168.0.1:18575] [
> AMQConnection] Connection 1 now connected from /192.168.0.2:48956 to
> myhost.example.com/192.168.0.1:18
> 575
> # Application thread gets in and creates a new session
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] SEND: [conn:eb35720] ch=2
> SessionAttach(name="916a6c14-069f-4cd0-ba8b-dde789766864")
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] SEND: [conn:eb35720] ch=2
> SessionRequestTimeout(timeout=0)
> # Failover begins to 'rewire' the existing JMS objects
> 2016-05-04 17:31:26,780 INFO [com/192.168.0.1:18575] [
> AMQConnectionDelegate_0_10] Resuming connection
> 2016-05-04 17:31:26,780 DEBUG [ app-listener-thread:01] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionAttach(name="edd4afef-052f-4dfc-8af0-ca96a887977c")
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 SessionRequestTimeout(timeout=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionCommandPoint(commandId=12383, commandOffset=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 id=12383 ExecutionSync()
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionCommandPoint(commandId=12384, commandOffset=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 SessionFlush(completed=true)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 id=12384 TxSelect()
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> # DEFECT Failover treats the application's new session as if it were an
> existing one
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
[jira] [Commented] (QPID-7255) Support delivery delay
[ https://issues.apache.org/jira/browse/QPID-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277801#comment-15277801 ] Rob Godfrey commented on QPID-7255: --- I don't see why an operator wouldn't be able to delete the message. A different question: would the message be available for browsing - my sense is not... I'm thinking that the implementation of this is that any such "held" message is treated as "acquired" by a "holding actor" within the broker. Whenever a consumer attempts to acquire a message the message checks to see if it should be held (if it is not already) or if it should be released (if it is currently held). Secondly the housekeeping process would cause the hold/release from hold check to be run against all messages in the queue. > Support delivery delay > -- > > Key: QPID-7255 > URL: https://issues.apache.org/jira/browse/QPID-7255 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Reporter: Keith Wall > > Some enterprise messaging systems provide a delayed delivery feature whereby > a publisher can provide a delivery time when sending the message, with the > Broker taking care of not making the message available to consumers until > that time is reached. The Java Broker should provide the same feature. > In the Java space, JMS 2.0 has standardised this feature, however there is > no reason why the feature could not be made available to older JMS 1.1 > clients using a Qpid specific header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7255) Support delivery delay
[ https://issues.apache.org/jira/browse/QPID-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277793#comment-15277793 ] Keith Wall commented on QPID-7255: -- What would an operator be able to do with a message that is still pending release? Would he be able to delete such a message even before its release time? > Support delivery delay > -- > > Key: QPID-7255 > URL: https://issues.apache.org/jira/browse/QPID-7255 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Reporter: Keith Wall > > Some enterprise messaging systems provide a delayed delivery feature whereby > a publisher can provide a delivery time when sending the message, with the > Broker taking care of not making the message available to consumers until > that time is reached. The Java Broker should provide the same feature. > In the Java space, JMS 2.0 has standardised this feature, however there is > no reason why the feature could not be made available to older JMS 1.1 > clients using a Qpid specific header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7255) Support delivery delay
Keith Wall created QPID-7255: Summary: Support delivery delay Key: QPID-7255 URL: https://issues.apache.org/jira/browse/QPID-7255 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Keith Wall Some enterprise messaging systems provide a delayed delivery feature whereby a publisher can provide a delivery time when sending the message, with the Broker taking care of not making the message available to consumers until that time is reached. The Java Broker should provide the same feature. In the Java space, JMS 2.0 has standardised this feature, however there is no reason why the feature could not be made available to older JMS 1.1 clients using a Qpid specific header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
