[jira] [Created] (QPID-6679) Unable to bound admin object for QpidDestinationProxy
Roman Syroeshko created QPID-6679:
-
Summary: Unable to bound admin object for QpidDestinationProxy
Key: QPID-6679
URL: https://issues.apache.org/jira/browse/QPID-6679
Project: Qpid
Issue Type: Bug
Components: JCA
Affects Versions: 0.32
Environment: WildFly 8.2.0.Final, JDK 1.8.0_45, Windows 8.1 x64.
Reporter: Roman Syroeshko
When I put the followed XML in RA configuration the admin object is not bound:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidDestinationProxy
jndi-name=java:/comp/env/jms/TheDestination pool-name=TheDestination
config-property name=DestinationType
QUEUE
/config-property
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
At the same time the followed config works OK:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidQueueImpl
jndi-name=java:/comp/env/jms/TheQueueBehindTheExchange
pool-name=TheQueueBehindTheExchange
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
Am I missing something, or bug takes place here?
--
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-6679) Unable to bound admin object for QpidDestinationProxy
[
https://issues.apache.org/jira/browse/QPID-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Syroeshko updated QPID-6679:
--
Description:
When I put the followed XML in RA configuration the admin object is not bound:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidDestinationProxy
jndi-name=java:/comp/env/jms/TheDestination pool-name=TheDestination
config-property name=DestinationType
QUEUE
/config-property
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
At the same time the followed config works OK:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidQueueImpl
jndi-name=java:/comp/env/jms/TheQueueBehindTheExchange
pool-name=TheQueueBehindTheExchange
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
Am I missing something, or bug takes place here?
was:
When I put the followed XML in RA configuration the admin object is not bound:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidDestinationProxy
jndi-name=java:/comp/env/jms/TheDestination pool-name=TheDestination
config-property name=DestinationType
QUEUE
/config-property
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
At the same time the followed config works OK:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidQueueImpl
jndi-name=java:/comp/env/jms/TheQueueBehindTheExchange
pool-name=TheQueueBehindTheExchange
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
Am I missing something, or bug takes place here?
Unable to bound admin object for QpidDestinationProxy
-
Key: QPID-6679
URL: https://issues.apache.org/jira/browse/QPID-6679
Project: Qpid
Issue Type: Bug
Components: JCA
Affects Versions: 0.32
Environment: WildFly 8.2.0.Final, JDK 1.8.0_45, Windows 8.1 x64.
Reporter: Roman Syroeshko
Labels: Destination
When I put the followed XML in RA configuration the admin object is not bound:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidDestinationProxy
jndi-name=java:/comp/env/jms/TheDestination pool-name=TheDestination
config-property name=DestinationType
QUEUE
/config-property
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
At the same time the followed config works OK:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidQueueImpl
jndi-name=java:/comp/env/jms/TheQueueBehindTheExchange
pool-name=TheQueueBehindTheExchange
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
Am I missing something, or bug takes place here?
--
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-6679) Unable to bound admin object for QpidDestinationProxy
[
https://issues.apache.org/jira/browse/QPID-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Syroeshko updated QPID-6679:
--
Labels: Destination QpidDestinationProxy (was: Destination)
Unable to bound admin object for QpidDestinationProxy
-
Key: QPID-6679
URL: https://issues.apache.org/jira/browse/QPID-6679
Project: Qpid
Issue Type: Bug
Components: JCA
Affects Versions: 0.32
Environment: WildFly 8.2.0.Final, JDK 1.8.0_45, Windows 8.1 x64.
Reporter: Roman Syroeshko
Labels: Destination, QpidDestinationProxy
When I put the followed XML in RA configuration the admin object is not bound:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidDestinationProxy
jndi-name=java:/comp/env/jms/TheDestination pool-name=TheDestination
config-property name=DestinationType
QUEUE
/config-property
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
At the same time the followed config works OK:
{code:xml}
admin-object class-name=org.apache.qpid.ra.admin.QpidQueueImpl
jndi-name=java:/comp/env/jms/TheQueueBehindTheExchange
pool-name=TheQueueBehindTheExchange
config-property name=DestinationAddress
BURL:direct://TheExchange//TheQueueBehindTheExchange?routingkey='TheQueueBehindTheExchange'amp;durable='true'amp;autodelete='false'amp;exchangedurable='true'amp;exchangeautodelete='false'
/config-property
/admin-object
{code}
Am I missing something, or bug takes place here?
--
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
Re: Review Request 36992: PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36992/
---
(Updated Aug. 5, 2015, 9:52 a.m.)
Review request for qpid, Kenneth Giusti and Ted Ross.
Changes
---
Improvements from kgiusti's feedback.
Repository: qpid-proton-git
Description
---
PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants.
Note:
{
I am skipping the java implementation for now,
because I would like to get the C version out of
my life. (And this diff is already quite large
enough, I think.)
I will write a separate JIRA for the java version
and make it refer to this one. I will work on it
as a background task.
}
This diff adds two pieces of functionality:
1. extract numeric default valuies from AMQP
xml files and store them as defined constants
in protocol.h (PROTON_930)
2. add code to enforce AMQP 1.0 spec mandated
behavior with respect to handle-max values
-- i.e. negotiated limits on number of links --
per session. (PROTON-886)
These two changes are combined into one checkin
because of some earlier feedback I got suggesting
that I not check in PROTON-930 until I had some
code that could actually use the constants that it
creates.
The code that is generated by the changes in
proton-c/src/protocol.h.py show up in the file
protocol.h. It is this:
- begin snippet ---
/* Numeric default values */
#define AMQP_OPEN_MAX_FRAME_SIZE_DEFAULT 4294967295
#define AMQP_OPEN_CHANNEL_MAX_DEFAULT 65535
#define AMQP_BEGIN_HANDLE_MAX_DEFAULT 4294967295
#define AMQP_SOURCE_TIMEOUT_DEFAULT 0
#define AMQP_TARGET_TIMEOUT_DEFAULT 0
- end snippet ---
Diffs (updated)
-
proton-c/bindings/python/proton/__init__.py 46b9466
proton-c/include/proton/session.h 94d2869
proton-c/src/engine/engine-internal.h 727f50d
proton-c/src/engine/engine.c 9043e0b
proton-c/src/protocol.h.py bbc0dfe
proton-c/src/transport/transport.c 6abf862
tests/python/proton_tests/engine.py 7a1d539
Diff: https://reviews.apache.org/r/36992/diff/
Testing
---
ctest -VV with Java tests running.
Thanks,
michael goulish
Re: Review Request 36992: PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants
On July 31, 2015, 8:27 p.m., Kenneth Giusti wrote:
proton-c/src/engine/engine.c, line 2230
https://reviews.apache.org/r/36992/diff/1/?file=1026182#file1026182line2230
use pn_min() in utils.h
Wow we ... have a min macro. I... That'sOK! Absolutely.
On July 31, 2015, 8:27 p.m., Kenneth Giusti wrote:
proton-c/src/protocol.h.py, line 39
https://reviews.apache.org/r/36992/diff/1/?file=1026183#file1026183line39
Yay! another chance to make you a Python programmer!
You don't need the standalone int conversion statement to test the type
(it's not 'natural' python):
int(default)
Use '%d' as the format flag (instead of %s), and pass it the
int(default) in the print() statement.
Bah. What's 'natural'? standalone makes the intent more clear. Now I'm
putting a comment there. Next they'll be telling me how to use whitespace.
Oh, wait...
- michael
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36992/#review93765
---
On Aug. 5, 2015, 9:52 a.m., michael goulish wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36992/
---
(Updated Aug. 5, 2015, 9:52 a.m.)
Review request for qpid, Kenneth Giusti and Ted Ross.
Repository: qpid-proton-git
Description
---
PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants.
Note:
{
I am skipping the java implementation for now,
because I would like to get the C version out of
my life. (And this diff is already quite large
enough, I think.)
I will write a separate JIRA for the java version
and make it refer to this one. I will work on it
as a background task.
}
This diff adds two pieces of functionality:
1. extract numeric default valuies from AMQP
xml files and store them as defined constants
in protocol.h (PROTON_930)
2. add code to enforce AMQP 1.0 spec mandated
behavior with respect to handle-max values
-- i.e. negotiated limits on number of links --
per session. (PROTON-886)
These two changes are combined into one checkin
because of some earlier feedback I got suggesting
that I not check in PROTON-930 until I had some
code that could actually use the constants that it
creates.
The code that is generated by the changes in
proton-c/src/protocol.h.py show up in the file
protocol.h. It is this:
- begin snippet ---
/* Numeric default values */
#define AMQP_OPEN_MAX_FRAME_SIZE_DEFAULT 4294967295
#define AMQP_OPEN_CHANNEL_MAX_DEFAULT 65535
#define AMQP_BEGIN_HANDLE_MAX_DEFAULT 4294967295
#define AMQP_SOURCE_TIMEOUT_DEFAULT 0
#define AMQP_TARGET_TIMEOUT_DEFAULT 0
- end snippet ---
Diffs
-
proton-c/bindings/python/proton/__init__.py 46b9466
proton-c/include/proton/session.h 94d2869
proton-c/src/engine/engine-internal.h 727f50d
proton-c/src/engine/engine.c 9043e0b
proton-c/src/protocol.h.py bbc0dfe
proton-c/src/transport/transport.c 6abf862
tests/python/proton_tests/engine.py 7a1d539
Diff: https://reviews.apache.org/r/36992/diff/
Testing
---
ctest -VV with Java tests running.
Thanks,
michael goulish
Re: [VOTE] Move Dispatch to git
We should move the code to git, Any way you look at it. It's the best code control system So new and shiny that it glistens. We should move it any day. We should move it right away. But one fact here we should construe. When I say We, I'm meaning You. :-) [X] Yes - move the qpid-dispatch repo to git [ ] No - no change: leave qpid-dispatch on subversion - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[
https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653924#comment-14653924
]
Alex Rudyy edited comment on QPID-3521 at 8/5/15 3:50 PM:
--
It seems that changes implemented in revision
[r1693542|https://svn.apache.org/r1693542] might cause a deadlock on 0-9 path
when Session is closed whilst failover is in progress. Here is the thread dump
demonstrating the issue:
{noformat}
Failover prio=10 tid=0x7fe0d804e000 nid=0x657c waiting on condition
[0x7fe0cf1f]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xf41c2528 (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at
org.apache.qpid.client.AMQSession.drainDispatchQueue(AMQSession.java:2306)
at
org.apache.qpid.client.AMQSession.drainDispatchQueueWithDispatcher(AMQSession.java:3697)
at
org.apache.qpid.client.AMQSession_0_8.resubscribe(AMQSession_0_8.java:186)
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.resubscribeSessions(AMQConnectionDelegate_8_0.java:379)
at
org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1387)
at
org.apache.qpid.client.failover.FailoverHandler.run(FailoverHandler.java:221)
- locked 0xf35412c0 (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
Dispatcher-2-Conn-84 prio=10 tid=0x7fe1341c nid=0x657a waiting for
monitor entry [0x7fe0cf4f3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3492)
- waiting to lock 0xf35c8e78 (a java.lang.Object)
- locked 0xf3cbea70 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3279)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3272)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3410)
- locked 0xf3cbea70 (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
main prio=10 tid=0x7fe134008800 nid=0x58f1 waiting for monitor entry
[0x7fe13d822000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.qpid.client.AMQSession.close(AMQSession.java:728)
- waiting to lock 0xf35412c0 (a java.lang.Object)
- locked 0xf35c8e78 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.close(AMQSession.java:447)
at
org.apache.qpid.client.failover.FailoverBehaviourTest.sessionCloseWhileFailoverImpl(FailoverBehaviourTest.java:1705)
at
org.apache.qpid.client.failover.FailoverBehaviourTest.testClientAcknowledgedSessionCloseWhileFailover(FailoverBehaviourTest.java:702)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:171)
at junit.framework.TestCase.runBare(TestCase.java:141)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:332)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:156)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
[jira] [Commented] (QPID-6670) Exchange deletion does not await binding deletion leading to possibility of a IllegalStateException : Task executor is not in ACTIVE state
[
https://issues.apache.org/jira/browse/QPID-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658422#comment-14658422
]
ASF subversion and git services commented on QPID-6670:
---
Commit 1694253 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1694253 ]
QPID-6670: [Java Broker] Delete future for queue/exchange must chain binding
deletion too
* Changed Queue/Exchange doDelete so that the future returned completes only
when the binding
children are also deleted too. Uses established doAfter/Async patterns
already adopted elsewhere
* On the 0-8..0-91 paths, close the session model object explicitly (like
0-10/1.0 paths) so that
io thread blocks until session close (rather than running asynchronously).
Exchange deletion does not await binding deletion leading to possibility of a
IllegalStateException : Task executor is not in ACTIVE state
--
Key: QPID-6670
URL: https://issues.apache.org/jira/browse/QPID-6670
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-6.0
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: qpid-java-6.0
As highlighted by
QueueDeclareTest.testDeclareIgnoresDurableFlagIfNonDurableQueueAlreadyExists
failing on Jenkins, there is a race between the bindings deletion (part of
which can happen asynchronously) and the shutdown of the virtualhost's task
executor.
In the unlucky case, the asynchronous task is submitted after the task
executor has shutdown.
This could manifest when stopping a VH (either by way of a Management
operation, Broker shutdown, or HA mastership change)
{noformat}
java.lang.IllegalStateException: Task executor is not in ACTIVE state
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.checkState(TaskExecutorImpl.java:310)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:141)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:499)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.setDesiredState(AbstractConfiguredObject.java:1315)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.deleteAsync(AbstractConfiguredObject.java:1837)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.delete(AbstractConfiguredObject.java:1766)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.exchange.AbstractExchange.removeBinding(AbstractExchange.java:666)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:na]
at
org.apache.qpid.server.exchange.AbstractExchange.access$000(AbstractExchange.java:80)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:na]
at
org.apache.qpid.server.exchange.AbstractExchange$1.stateChanged(AbstractExchange.java:138)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:na]
at
org.apache.qpid.server.exchange.AbstractExchange$1.stateChanged(AbstractExchange.java:132)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:na]
at
org.apache.qpid.server.binding.BindingImpl.doDelete(BindingImpl.java:208)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.7.0_67]
at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_67]
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1194)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfOpenedOrReopenFailed(AbstractConfiguredObject.java:1162)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$1500(AbstractConfiguredObject.java:83)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject$15.call(AbstractConfiguredObject.java:1354)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.apache.qpid.server.model.AbstractConfiguredObject$15.call(AbstractConfiguredObject.java:1316)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
[jira] [Commented] (QPID-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[ https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658427#comment-14658427 ] ASF subversion and git services commented on QPID-3521: --- Commit 1694254 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1694254 ] QPID-3521: [Java Client] Stop using dispatcher to clear pre-dispatch queue on 0.8/0.9.x client in order to avoid dead locks. Address review comments. failover process for the 0-8 client does not clear the pre-dispatch queue - Key: QPID-3521 URL: https://issues.apache.org/jira/browse/QPID-3521 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Robbie Gemmell Assignee: Keith Wall Labels: failover Attachments: clear-dispatch-queue-on-failover.diff failover process for the 0-8 client does not clear the pre-dispatch queue, only the consumer receive queue. This is currently masked by an issue with the rollbackMark. The changes made in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1 client path when this issue is resolved. -- 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-6677) Invocation of Connection#stop from MessageListener with 0-10 AMQP client might result in hang of operation
[ https://issues.apache.org/jira/browse/QPID-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-6677. -- Resolution: Fixed Assignee: Alex Rudyy Fixed as part of QPID-3521 Invocation of Connection#stop from MessageListener with 0-10 AMQP client might result in hang of operation -- Key: QPID-6677 URL: https://issues.apache.org/jira/browse/QPID-6677 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.30, 0.32 Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: qpid-java-6.0 Invocation of Connection#stop from MessageListener with 0-10 AMQP client might result in hang of operation due to usage of dispatcher to drain the pre-dispatch queue. If stopped flag is set to true, the dispatcher waits until stopped flag is set to false, stopping the message dispatching. As result, operation might hang. -- 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-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[
https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658682#comment-14658682
]
Keith Wall commented on QPID-3521:
--
It appears that commit r1694254 is causing a unit test failure:
{noformat}
Running org.apache.qpid.client.AMQSession_0_8Test
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.682 sec
FAILURE! - in org.apache.qpid.client.AMQSession_0_8Test
testResubscribe(org.apache.qpid.client.AMQSession_0_8Test) Time elapsed: 0.369
sec FAILURE!
org.mockito.exceptions.verification.WantedButNotInvoked:
Wanted but not invoked:
unprocessedMessage.dispatch(
org.apache.qpid.client.AMQSession_0_8@6f7923a5
);
- at
org.apache.qpid.client.AMQSession_0_8Test.testResubscribe(AMQSession_0_8Test.java:165)
However, there were other interactions with this mock:
- at org.apache.qpid.client.AMQSession.messageReceived(AMQSession.java:1712)
at
org.apache.qpid.client.AMQSession_0_8Test.testResubscribe(AMQSession_0_8Test.java:165)
Results :
Failed tests:
AMQSession_0_8TestQpidTestCase.run:156-QpidTestCase.runTest:171-testResubscribe:165
Wanted but not invoked:
unprocessedMessage.dispatch(
org.apache.qpid.client.AMQSession_0_8@6f7923a5
);
- at
org.apache.qpid.client.AMQSession_0_8Test.testResubscribe(AMQSession_0_8Test.java:165)
However, there were other interactions with this mock:
- at org.apache.qpid.client.AMQSession.messageReceived(AMQSession.java:1712)
{noformat}
failover process for the 0-8 client does not clear the pre-dispatch queue
-
Key: QPID-3521
URL: https://issues.apache.org/jira/browse/QPID-3521
Project: Qpid
Issue Type: Bug
Components: Java Client
Reporter: Robbie Gemmell
Assignee: Keith Wall
Labels: failover
Attachments: clear-dispatch-queue-on-failover.diff
failover process for the 0-8 client does not clear the pre-dispatch queue,
only the consumer receive queue.
This is currently masked by an issue with the rollbackMark. The changes made
in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1
client path when this issue is resolved.
--
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-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[ https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3521: - Assignee: Alex Rudyy (was: Keith Wall) failover process for the 0-8 client does not clear the pre-dispatch queue - Key: QPID-3521 URL: https://issues.apache.org/jira/browse/QPID-3521 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Robbie Gemmell Assignee: Alex Rudyy Labels: failover Attachments: clear-dispatch-queue-on-failover.diff failover process for the 0-8 client does not clear the pre-dispatch queue, only the consumer receive queue. This is currently masked by an issue with the rollbackMark. The changes made in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1 client path when this issue is resolved. -- 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] (QPID-6429) IO refactoring - use single pooled thread to service each connection
[ https://issues.apache.org/jira/browse/QPID-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-6429. Resolution: Fixed IO refactoring - use single pooled thread to service each connection Key: QPID-6429 URL: https://issues.apache.org/jira/browse/QPID-6429 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-6.0 Change Broker threading model to utilise a thread pool to service IO requests. Refactor protocol parts so that management actions (such as connection close) no longer push frames directly onto into transport, instead management actions merely inform the protocol layer that there is a task to be done and cause the IO layer to be schedule, letting the IO thread perform the protocol action itself. -- 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-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[ https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658742#comment-14658742 ] Rob Godfrey commented on QPID-3521: --- What's the rationale for adding the ConnectionHelper class - moving the functionality from AMQConnection to a static method which then operates on the connection? Refactoring in this way doesn't seem to add any tangible benefits and seems simply to move methods from the class they affect to a separate file. There's certainly a lot of valuable refactoring that could be done around the client... but I'm not sure this is really an improvement failover process for the 0-8 client does not clear the pre-dispatch queue - Key: QPID-3521 URL: https://issues.apache.org/jira/browse/QPID-3521 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Robbie Gemmell Assignee: Alex Rudyy Labels: failover Attachments: clear-dispatch-queue-on-failover.diff failover process for the 0-8 client does not clear the pre-dispatch queue, only the consumer receive queue. This is currently masked by an issue with the rollbackMark. The changes made in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1 client path when this issue is resolved. -- 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-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[ https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658768#comment-14658768 ] ASF subversion and git services commented on QPID-3521: --- Commit 1694307 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1694307 ] QPID-3521: Fix failing test and remove FailoverBehaviourTest#testFailoverWhenConnectionStopped from cpp excludes failover process for the 0-8 client does not clear the pre-dispatch queue - Key: QPID-3521 URL: https://issues.apache.org/jira/browse/QPID-3521 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Robbie Gemmell Assignee: Alex Rudyy Labels: failover Attachments: clear-dispatch-queue-on-failover.diff failover process for the 0-8 client does not clear the pre-dispatch queue, only the consumer receive queue. This is currently masked by an issue with the rollbackMark. The changes made in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1 client path when this issue is resolved. -- 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-6680) [C++] .NET Binding does not handle UTF8 message body, map key name
Chuck Rolke created QPID-6680: - Summary: [C++] .NET Binding does not handle UTF8 message body, map key name Key: QPID-6680 URL: https://issues.apache.org/jira/browse/QPID-6680 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: qpid-cpp-0.34 Environment: Windows Visual Studio - all, .NET Framework all Reporter: Chuck Rolke Assignee: Chuck Rolke https://github.com/apache/qpid/pull/8 suggests a method to use UTF8 strings in message bodies. The patch also allows UTF8 strings as key names in maps. These are good ideas with the following additions: 1. It needs a jira, and this is it. 2. QpidMarshal.h:73 has warnings without an explicit int cast 3. TypeTranslator.cpp:283 calls QpidMarshal::ToNative. I think the intent is to call ::ToManaged. The ';;' suggests some cut and paste going on to produce the pull request from a larger set of changes... 4. No self test. -- 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 pull request: NO-JIRA: Fixed .NET Native-Managed string conve...
Github user asfgit closed the pull request at: https://github.com/apache/qpid/pull/8 --- 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-6680) [C++] .NET Binding does not handle UTF8 message body, map key name
[ https://issues.apache.org/jira/browse/QPID-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658882#comment-14658882 ] ASF subversion and git services commented on QPID-6680: --- Commit 1694323 from c...@apache.org in branch 'qpid/trunk' [ https://svn.apache.org/r1694323 ] QPID-6680: .NET Binding allows UTF-8 string messages - patch from https://github.com/gaborsulyok This closes #8 [C++] .NET Binding does not handle UTF8 message body, map key name -- Key: QPID-6680 URL: https://issues.apache.org/jira/browse/QPID-6680 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: qpid-cpp-0.34 Environment: Windows Visual Studio - all, .NET Framework all Reporter: Chuck Rolke Assignee: Chuck Rolke https://github.com/apache/qpid/pull/8 suggests a method to use UTF8 strings in message bodies. The patch also allows UTF8 strings as key names in maps. These are good ideas with the following additions: 1. It needs a jira, and this is it. 2. QpidMarshal.h:73 has warnings without an explicit int cast 3. TypeTranslator.cpp:283 calls QpidMarshal::ToNative. I think the intent is to call ::ToManaged. The ';;' suggests some cut and paste going on to produce the pull request from a larger set of changes... 4. No self test. -- 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
Re: Review Request 36992: PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36992/#review94317
---
Ship it!
Ship It!
- Kenneth Giusti
On Aug. 5, 2015, 9:52 a.m., michael goulish wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36992/
---
(Updated Aug. 5, 2015, 9:52 a.m.)
Review request for qpid, Kenneth Giusti and Ted Ross.
Repository: qpid-proton-git
Description
---
PROTON-886 and PROTON-930 -- handle_max and AMQP numeric default constants.
Note:
{
I am skipping the java implementation for now,
because I would like to get the C version out of
my life. (And this diff is already quite large
enough, I think.)
I will write a separate JIRA for the java version
and make it refer to this one. I will work on it
as a background task.
}
This diff adds two pieces of functionality:
1. extract numeric default valuies from AMQP
xml files and store them as defined constants
in protocol.h (PROTON_930)
2. add code to enforce AMQP 1.0 spec mandated
behavior with respect to handle-max values
-- i.e. negotiated limits on number of links --
per session. (PROTON-886)
These two changes are combined into one checkin
because of some earlier feedback I got suggesting
that I not check in PROTON-930 until I had some
code that could actually use the constants that it
creates.
The code that is generated by the changes in
proton-c/src/protocol.h.py show up in the file
protocol.h. It is this:
- begin snippet ---
/* Numeric default values */
#define AMQP_OPEN_MAX_FRAME_SIZE_DEFAULT 4294967295
#define AMQP_OPEN_CHANNEL_MAX_DEFAULT 65535
#define AMQP_BEGIN_HANDLE_MAX_DEFAULT 4294967295
#define AMQP_SOURCE_TIMEOUT_DEFAULT 0
#define AMQP_TARGET_TIMEOUT_DEFAULT 0
- end snippet ---
Diffs
-
proton-c/bindings/python/proton/__init__.py 46b9466
proton-c/include/proton/session.h 94d2869
proton-c/src/engine/engine-internal.h 727f50d
proton-c/src/engine/engine.c 9043e0b
proton-c/src/protocol.h.py bbc0dfe
proton-c/src/transport/transport.c 6abf862
tests/python/proton_tests/engine.py 7a1d539
Diff: https://reviews.apache.org/r/36992/diff/
Testing
---
ctest -VV with Java tests running.
Thanks,
michael goulish
