[jira] [Updated] (QPID-7910) [Java Broker] Improve qpid.stop script

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-7910:
-
Attachment: qpid-stop

Attached improved version of qpid stop script

> [Java Broker] Improve qpid.stop script
> --
>
> Key: QPID-7910
> URL: https://issues.apache.org/jira/browse/QPID-7910
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: qpid-stop
>
>
> Java Broker qpid.stop  needs improvements:
> * it  currently tries to send SIGTERM and SIGKILL commands twice. It is 
> superfluous. Sending event once should be sufficient. 
> * we can use {{kill -0}} to verify the process instead of using ps
> * make {{$SLEEP_DELAY}} overridable from command line
> * script should be able to wait until Qpid processes are killed before exiting



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-209) Three+ router test is needed in the system test suite.

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-209:
--
Issue Type: Improvement  (was: New Feature)

> Three+ router test is needed in the system test suite.
> --
>
> Key: DISPATCH-209
> URL: https://issues.apache.org/jira/browse/DISPATCH-209
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Ted Ross
>Assignee: michael goulish
> Fix For: 1.0.0
>
>
> There have arisen some issues that would have been caught had there been a 
> three-router test in the regression suite.  This test should be added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-767:
--
Issue Type: New Feature  (was: Improvement)

> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-803) refuse attach to undefined addresses

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-803:
--
Issue Type: New Feature  (was: Improvement)

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-818) Honor failoverList provided by connected brokers

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-818:
--
Issue Type: New Feature  (was: Bug)

> Honor failoverList provided by connected brokers
> 
>
> Key: DISPATCH-818
> URL: https://issues.apache.org/jira/browse/DISPATCH-818
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When a router makes a connection to a broker (using a configured connector), 
> the broker may provide alternate connection information for use in a failure 
> scenario. The router must honor this alternate connection data when the 
> primary connection is lost.
> For example, if the router opens a connection to the broker and the broker 
> responds with an open frame like the following - 
> {noformat}
> [0x7fc8b000a3e0]:0 <- @open(16) [container-id="Router.A", 
> max-frame-size=16384, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0", 
> :"failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]}]
> {noformat}
> notice that the broker sends a failover-server-list of 
> {noformat}
> "failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]
> {noformat}
> The router should store this alternate connection information and retry these 
> hosts when the original connection goes down.
> The following should be the order of operations
>  - The original connection goes down, try connecting with the original 
> connection information one more time. If that failed, try connecting with the 
> alternate connection information. If the original and the alternate failed, 
> keep going round robin between alternate and original until you get a 
> successful hit.
> - If there is no alternate connection information, keep on trying to connect 
> using the original connection information (which is what is currently 
> happening).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-813) Support wildcard format for link-routes

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-813:
--
Issue Type: New Feature  (was: Improvement)

> Support wildcard format for link-routes
> ---
>
> Key: DISPATCH-813
> URL: https://issues.apache.org/jira/browse/DISPATCH-813
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ken Giusti
> Fix For: 1.0.0
>
>
> Replicate the feature developed for DISPATCH-731 for link-routes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-844) Make TLS cipher suites configurable

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-844:
--
Issue Type: New Feature  (was: Bug)

> Make TLS cipher suites configurable
> ---
>
> Key: DISPATCH-844
> URL: https://issues.apache.org/jira/browse/DISPATCH-844
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> A security conscious user may wish to restrict the set of ciphers to a 
> minimal set of those that are currently deemed secure.
> Proton now allows TLS cipher suites to be configurable as seen in 
> https://issues.apache.org/jira/browse/PROTON-1582
> Introduce a field called "ciphers" in sslProfile and call 
> pn_ssl_domain_set_ciphers if ciphers field is provided by the user.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-731:
--
Issue Type: New Feature  (was: Improvement)

> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209832#comment-16209832
 ] 

ASF subversion and git services commented on QPID-7975:
---

Commit fc377333e4d3b666df750c090e12e608dce8012d in qpid-cpp's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=fc37733 ]

QPID-7975: Fixed a syntax error that affects earlier c++ compilers


> [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently 
> causes high latency for 1.0 messages
> 
>
> Key: QPID-7975
> URL: https://issues.apache.org/jira/browse/QPID-7975
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>
> When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
> concurrently, a condition is triggered where the store no longer flushes the 
> 1.0 messages. When this condition is triggered, the 1.0 messages are flushed 
> by the 0-10 activity on the queue, or if there is none, then the messages are 
> never flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (PROTON-1625) [c, examples] receiver does not dispose of aborted message data

[Chuck Rolke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chuck Rolke closed PROTON-1625.
---
Resolution: Invalid

> [c, examples] receiver does not dispose of aborted message data
> ---
>
> Key: PROTON-1625
> URL: https://issues.apache.org/jira/browse/PROTON-1625
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Reopened] (PROTON-1625) [c, examples] receiver does not dispose of aborted message data

[Chuck Rolke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chuck Rolke reopened PROTON-1625:
-

> [c, examples] receiver does not dispose of aborted message data
> ---
>
> Key: PROTON-1625
> URL: https://issues.apache.org/jira/browse/PROTON-1625
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1625) [c, examples] receiver does not dispose of aborted message data

[Chuck Rolke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chuck Rolke updated PROTON-1625:

Fix Version/s: (was: proton-c-0.18.0)

> [c, examples] receiver does not dispose of aborted message data
> ---
>
> Key: PROTON-1625
> URL: https://issues.apache.org/jira/browse/PROTON-1625
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7979) [Java Broker] [JDBC] Some exception causes are hidden

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209694#comment-16209694
 ] 

ASF subversion and git services commented on QPID-7979:
---

Commit a213b5d43553e9db644473ee22132ab95e8792d0 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a213b5d ]

QPID-7979: [Java Broker] [JDBC Message Store] Include the underlying 
SQLException when the database connection fails.


> [Java Broker] [JDBC] Some exception causes are hidden
> -
>
> Key: QPID-7979
> URL: https://issues.apache.org/jira/browse/QPID-7979
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> As reported in this thread, there is one place in the the JDBC code that, 
> when wrapping a SQLException, fails to include the original exception as an 
> initial cause.
> http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-6-1-4-Some-expections-are-hidden-td7668030.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7979) [Java Broker] [JDBCMessageStore] Some exception causes are hidden

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7979:
-
Summary: [Java Broker] [JDBCMessageStore] Some exception causes are hidden  
(was: [Java Broker] [JDBC] Some exception causes are hidden)

> [Java Broker] [JDBCMessageStore] Some exception causes are hidden
> -
>
> Key: QPID-7979
> URL: https://issues.apache.org/jira/browse/QPID-7979
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> As reported in this thread, there is one place in the the JDBC code that, 
> when wrapping a SQLException, fails to include the original exception as an 
> initial cause.
> http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-6-1-4-Some-expections-are-hidden-td7668030.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7979) [Java Broker] [JDBC] Some exception causes are hidden

[Keith Wall (JIRA)]

Keith Wall created QPID-7979:


 Summary: [Java Broker] [JDBC] Some exception causes are hidden
 Key: QPID-7979
 URL: https://issues.apache.org/jira/browse/QPID-7979
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Keith Wall
Priority: Minor
 Fix For: qpid-java-broker-7.0.0


As reported in this thread, there is one place in the the JDBC code that, when 
wrapping a SQLException, fails to include the original exception as an initial 
cause.

http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-6-1-4-Some-expections-are-hidden-td7668030.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7978) [Java Broker] [AMQP 1-0] Protocol test cases outgoing transfer leak direct memory

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7978:
-
Attachment: 
TEST-org.apache.qpid.tests.protocol.v1_0.transport.link.AttachTest.emptyAttach.txt

> [Java Broker] [AMQP 1-0] Protocol test cases outgoing transfer leak direct 
> memory
> -
>
> Key: QPID-7978
> URL: https://issues.apache.org/jira/browse/QPID-7978
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Tests
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.tests.protocol.v1_0.transport.link.AttachTest.emptyAttach.txt
>
>
> It was noticed during QPID-7832, that the protocol tests themselves were 
> leaking direct memory.   It is not impactful to the tests themselves, but 
> creates false positives whilst looking for leaks elsewhere.
> When the {{Interaction}} orchestrates a {{Transfer}}. we currently fail to 
> dispose of the QBBs beneath the original transfer itself.  The copies - which 
> go to the wire are disposed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7832) Refactor store/protocol API using Collection

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209628#comment-16209628
 ] 

Rob Godfrey commented on QPID-7832:
---

Ah - I see it has already been applied - but the commit message hasn't made it 
to JIRA yet :-)

The general point about larger pieces of work still stands though I think

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-1603) Windows C++ container does not compile multithreaded

[Andrew Stitcher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher resolved PROTON-1603.
-
Resolution: Cannot Reproduce

> Windows C++ container does not compile multithreaded
> 
>
> Key: PROTON-1603
> URL: https://issues.apache.org/jira/browse/PROTON-1603
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Cliff Jansen
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> For both VS2013 and VS2017 cmake proclaims:
>   HAS_STD_THREAD - Success
>   HAS_STD_MUTEX - Success
>   HAS_STD_ATOMIC - Success
> yet proactor_container_impl.cpp does not compile
> PN_CPP_SUPPORTS_THREADS sections.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-834) Create config tool to create/read/update/delete router config files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209622#comment-16209622
 ] 

ASF subversion and git services commented on DISPATCH-834:
--

Commit c9100825c04b73a41d066b8a0ef099db9afb9889 in qpid-dispatch's branch 
refs/heads/config-read-write from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c910082 ]

DISPATCH-834 Check-in missing change to router edit dialog


> Create config tool to create/read/update/delete router config files
> ---
>
> Key: DISPATCH-834
> URL: https://issues.apache.org/jira/browse/DISPATCH-834
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Console
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>
> Create a UI and supporting program that reads/updates/writes/deletes router 
> config files.
> It should at least:
> - read all config files in a directory and display a topology
> - create new directories to store config files
> - create connectors/listeners between routers with correct host:port
> - allow creating/editing/deleting of external 
> listeners/connectors/sslProfiles/log sections
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7832) Refactor store/protocol API using Collection

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209619#comment-16209619
 ] 

Rob Godfrey commented on QPID-7832:
---

This looks like it could be quite a substantial change - would it make sense to 
have this up as a branch / PR somewhere that people can see evolving?

I guess this is a general process question for whenever people are working on 
larger changes

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1636) Fairly Consistent (but intermittent) hangs in ruby-example-test using Travis CI

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1636:

Fix Version/s: (was: proton-c-0.18.0)
   proton-c-0.19.0

> Fairly Consistent (but intermittent) hangs in ruby-example-test using Travis 
> CI
> ---
>
> Key: PROTON-1636
> URL: https://issues.apache.org/jira/browse/PROTON-1636
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: Travis CI:
> Ubuntu 1404 with lots of changes
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> This is pretty annoying as it makes the build fail about 50% of the time for 
> me and so it looks like the change just made failed the build.
> {noformat}
>   Start 14: ruby-example-test
> 14: Test command: /home/travis/.rvm/rubies/ruby-2.4.1/bin/ruby 
> "example_test.rb" "-v"
> 14: Test timeout computed to be: 1500
> 14: Run options: -v --seed 7224
> 14: 
> 14: # Running:
> 14: 
> 14: ExampleTest#test_client_server = 0.30 s = .
> No output has been received in the last 10m0s, this potentially indicates a 
> stalled build or something wrong with the build itself.
> Check the details on how to adjust your build configuration on: 
> https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
> The build has been terminated
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1637) C++ binding relies on private symbols from proton-core library

[Andrew Stitcher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher updated PROTON-1637:

Fix Version/s: (was: proton-c-0.18.0)
   proton-c-0.19.0

> C++ binding relies on private symbols from proton-core library
> --
>
> Key: PROTON-1637
> URL: https://issues.apache.org/jira/browse/PROTON-1637
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.19.0
>
>
> The C++ binding relies on some "internal" symbols or the proton-core library
> Notably {{pni_message_with_extra()}} &{{pni_message_get_extra()}}. But also 
> {{pni_log_enabled()}} etc. too
> The proton-core library is supposed to export everything needed by bindings 
> publically so that there is no "under-the-covers" private agreement between 
> them.
> There isn't really any other way to allow bindings to be generally written.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1620) TLS / SSL thread safety with proactor

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1620:

Fix Version/s: (was: proton-c-0.18.0)
   proton-c-0.19.0

> TLS / SSL thread safety with proactor
> -
>
> Key: PROTON-1620
> URL: https://issues.apache.org/jira/browse/PROTON-1620
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Cliff Jansen
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.19.0
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (PROTON-1620) TLS / SSL thread safety with proactor

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway reassigned PROTON-1620:
---

Assignee: Alan Conway

> TLS / SSL thread safety with proactor
> -
>
> Key: PROTON-1620
> URL: https://issues.apache.org/jira/browse/PROTON-1620
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Cliff Jansen
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.19.0
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Attachment: MultiNodeTest.tar.bz2

> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Attachments: MultiNodeTest.tar.bz2
>
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operations that occur after fail.  One possible place this can occur 
> is the is the rolling back open transactions. The rollback causes the store 
> to try and remove the messages 
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
>   The underlying database operation fails on line 
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
>  This prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.
> The non-HA use-case is unaffected.
> Example database exception{noformat}
> 2017-10-18 17:03:32,544 BROKER-52 ERROR [IO-/127.0.0.1:62547] 
> o.a.q.s.s.b.BDBConfigurationStore Unexpected BDB exception
> com.sleepycat.je.rep.ReplicaWriteException: (JE 7.4.5) Problem closing 
> transaction 14. The current state is:UNKNOWN. The node transitioned to this 
> state at:Wed Oct 18 17:03:32 BST 2017
> at 
> com.sleepycat.je.rep.txn.ReadonlyTxn.disallowReplicaWrite(ReadonlyTxn.java:114)
> at 
> com.sleepycat.je.rep.txn.ReadonlyTxn.lockInternal(ReadonlyTxn.java:86)
> at com.sleepycat.je.txn.Locker.nonBlockingLock(Locker.java:534)
> at com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:3606)
> at 
> com.sleepycat.je.dbi.CursorImpl.deleteCurrentRecord(CursorImpl.java:900)
> at com.sleepycat.je.Cursor.deleteNoNotify(Cursor.java:2412)
> at com.sleepycat.je.Cursor.deleteInternal(Cursor.java:2353)
> at com.sleepycat.je.Database.deleteInternal(Database.java:1169)
> at com.sleepycat.je.Database.delete(Database.java:1128)
> at com.sleepycat.je.Database.delete(Database.java:1230)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:273)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1085)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309)
> at 
> org.apache.qpid.server.message.RoutingResult$1.onRollback(RoutingResult.java:131)
> at 
> org.apache.qpid.server.txn.LocalTransaction$4.onRollback(LocalTransaction.java:315)
> at 
> org.apache.qpid.server.txn.LocalTransaction.doRollbackActions(LocalTransaction.java:386)
> at 
> org.apache.qpid.server.txn.LocalTransaction.rollback(LocalTransaction.java:462)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:802)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:778)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeAllChannels(AMQPConnection_0_8Impl.java:487)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.completeAndCloseAllChannels(AMQPConnection_0_8Impl.java:521)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closed(AMQPConnection_0_8Impl.java:668)
> at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:101)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:385)
> at 
> 

[jira] [Commented] (QPID-7832) Refactor store/protocol API using Collection

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209617#comment-16209617
 ] 

Keith Wall commented on QPID-7832:
--

Lorenz and I paired on this work.

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7832) Refactor store/protocol API using Collection

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7832.
--
Resolution: Fixed

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages 
{{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.

The non-HA use-case is unaffected.

Example database exception{noformat}
2017-10-18 17:03:32,544 BROKER-52 ERROR [IO-/127.0.0.1:62547] 
o.a.q.s.s.b.BDBConfigurationStore Unexpected BDB exception
com.sleepycat.je.rep.ReplicaWriteException: (JE 7.4.5) Problem closing 
transaction 14. The current state is:UNKNOWN. The node transitioned to this 
state at:Wed Oct 18 17:03:32 BST 2017
at 
com.sleepycat.je.rep.txn.ReadonlyTxn.disallowReplicaWrite(ReadonlyTxn.java:114)
at 
com.sleepycat.je.rep.txn.ReadonlyTxn.lockInternal(ReadonlyTxn.java:86)
at com.sleepycat.je.txn.Locker.nonBlockingLock(Locker.java:534)
at com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:3606)
at 
com.sleepycat.je.dbi.CursorImpl.deleteCurrentRecord(CursorImpl.java:900)
at com.sleepycat.je.Cursor.deleteNoNotify(Cursor.java:2412)
at com.sleepycat.je.Cursor.deleteInternal(Cursor.java:2353)
at com.sleepycat.je.Database.deleteInternal(Database.java:1169)
at com.sleepycat.je.Database.delete(Database.java:1128)
at com.sleepycat.je.Database.delete(Database.java:1230)
at 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:273)
at 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1085)
at 
org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118)
at 
org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
at 
org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309)
at 
org.apache.qpid.server.message.RoutingResult$1.onRollback(RoutingResult.java:131)
at 
org.apache.qpid.server.txn.LocalTransaction$4.onRollback(LocalTransaction.java:315)
at 
org.apache.qpid.server.txn.LocalTransaction.doRollbackActions(LocalTransaction.java:386)
at 
org.apache.qpid.server.txn.LocalTransaction.rollback(LocalTransaction.java:462)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:802)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:778)
at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeAllChannels(AMQPConnection_0_8Impl.java:487)
at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.completeAndCloseAllChannels(AMQPConnection_0_8Impl.java:521)
at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closed(AMQPConnection_0_8Impl.java:668)
at 
org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:101)
at 
org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:385)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:313)
at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 

[jira] [Commented] (DISPATCH-834) Create config tool to create/read/update/delete router config files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209605#comment-16209605
 ] 

ASF subversion and git services commented on DISPATCH-834:
--

Commit e1418ab53a8219d9e5a0aff5a126f7fb732d0cb4 in qpid-dispatch's branch 
refs/heads/config-read-write from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e1418ab ]

DISPATCH-834 Handle changing between address.prefix and address.pattern


> Create config tool to create/read/update/delete router config files
> ---
>
> Key: DISPATCH-834
> URL: https://issues.apache.org/jira/browse/DISPATCH-834
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Console
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>
> Create a UI and supporting program that reads/updates/writes/deletes router 
> config files.
> It should at least:
> - read all config files in a directory and display a topology
> - create new directories to store config files
> - create connectors/listeners between routers with correct host:port
> - allow creating/editing/deleting of external 
> listeners/connectors/sslProfiles/log sections
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7978) [Java Broker] [AMQP 1-0] Protocol test cases outgoing transfer leak direct memory

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7978:
-
Priority: Minor  (was: Major)

> [Java Broker] [AMQP 1-0] Protocol test cases outgoing transfer leak direct 
> memory
> -
>
> Key: QPID-7978
> URL: https://issues.apache.org/jira/browse/QPID-7978
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Tests
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> It was noticed during QPID-7832, that the protocol tests themselves were 
> leaking direct memory.   It is not impactful to the tests themselves, but 
> creates false positives whilst looking for leaks elsewhere.
> When the {{Interaction}} orchestrates a {{Transfer}}. we currently fail to 
> dispose of the QBBs beneath the original transfer itself.  The copies - which 
> go to the wire are disposed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7978) [Java Broker] [AMQP 1-0] Protocol test cases outgoing transfer leak direct memory

[Keith Wall (JIRA)]

Keith Wall created QPID-7978:


 Summary: [Java Broker] [AMQP 1-0] Protocol test cases outgoing 
transfer leak direct memory
 Key: QPID-7978
 URL: https://issues.apache.org/jira/browse/QPID-7978
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker, Java Tests
Affects Versions: qpid-java-broker-7.0.0
Reporter: Keith Wall


It was noticed during QPID-7832, that the protocol tests themselves were 
leaking direct memory.   It is not impactful to the tests themselves, but 
creates false positives whilst looking for leaks elsewhere.

When the {{Interaction}} orchestrates a {{Transfer}}. we currently fail to 
dispose of the QBBs beneath the original transfer itself.  The copies - which 
go to the wire are disposed.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Priority: Minor  (was: Major)

> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operations that occur after fail.  One possible place this can occur 
> is the is the rolling back open transactions. The rollback causes the store 
> to try and remove the messages 
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
>   The underlying database operation fails on line 
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
>  This prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.
> The non-HA use-case is unaffected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages {{ 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.



  was:
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.




> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operations that occur after fail.  One possible place this can occur 
> is the is the rolling back open transactions. The rollback causes the store 
> to try and remove the messages {{ 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
>   The underlying database operation fails on line 
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
>  This prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages 
{{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.

The non-HA use-case is unaffected.


  was:
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages {{ 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.

The non-HA use-case is unaffected.



> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operations that occur after fail.  One possible place this can occur 
> is the is the rolling back open transactions. The rollback causes the store 
> to try and remove the messages 
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
>   The underlying database operation fails on line 
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
>  This prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.
> The non-HA use-case is unaffected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages {{ 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.

The non-HA use-case is unaffected.


  was:
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operations that occur after fail.  One possible place this can occur is the is 
the rolling back open transactions. The rollback causes the store to try and 
remove the messages {{ 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
  The underlying database operation fails on line 
{{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}. 
This prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.




> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operations that occur after fail.  One possible place this can occur 
> is the is the rolling back open transactions. The rollback causes the store 
> to try and remove the messages {{ 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove}}.
>   The underlying database operation fails on line 
> {{org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085}}.
>  This prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.
> The non-HA use-case is unaffected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leaked when a node loses the 
mastership. 

The test that exposed the direct leak is: 
{{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.



  was:
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leak when a node loses the 
mastership. 

The test that exposed the direct leak is: 
org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.




> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leaked when a node 
> loses the mastership. 
> The test that exposed the direct leak is: 
> {{org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover}}
> I think the problem is this.  When mastership is lost, the underlying 
> database operation fail.  For instance, the virtualhost that was master is 
> rolling back open transactions.  This causes the messages that were committed 
> to the store to be removed 
> (org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
>   The underlying database operation fails 
> (org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
> this prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Affects Version/s: qpid-java-broker-7.0.0
   qpid-java-6.0
   qpid-java-6.1

> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leak when a node loses 
> the mastership. 
> The test that exposed the direct leak is: 
> org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover
> I think the problem is this.  When mastership is lost, the underlying 
> database operation fail.  For instance, the virtualhost that was master is 
> rolling back open transactions.  This causes the messages that were committed 
> to the store to be removed 
> (org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
>   The underlying database operation fails 
> (org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
> this prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7977:
-
Description: 
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leak when a node loses the 
mastership. 

The test that exposed the direct leak is: 
org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.   One possible fix is a simple try/finally.  There might be other 
places that need similar attention.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.



  was:
During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leak when a node loses the 
mastership. 

The test that exposed the direct leak is: 
org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.



> [Java Broker] [HA] Direct memory leak possible when mastership is lost
> --
>
> Key: QPID-7977
> URL: https://issues.apache.org/jira/browse/QPID-7977
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>
> During the work of QPID-7832, it was noticed that there is a potential for 
> the direct memory used for uncommitted messages to be leak when a node loses 
> the mastership. 
> The test that exposed the direct leak is: 
> org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover
> I think the problem is this.  When mastership is lost, the underlying 
> database operation fail.  For instance, the virtualhost that was master is 
> rolling back open transactions.  This causes the messages that were committed 
> to the store to be removed 
> (org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
>   The underlying database operation fails 
> (org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
> this prevents the direct memory associated with the messages from being 
> released.   One possible fix is a simple try/finally.  There might be other 
> places that need similar attention.
> The operation of the group is unaffected, and there is no message loss.  The 
> JVM should eventually release the direct memory itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7977) [Java Broker] [HA] Direct memory leak possible when mastership is lost

[Keith Wall (JIRA)]

Keith Wall created QPID-7977:


 Summary: [Java Broker] [HA] Direct memory leak possible when 
mastership is lost
 Key: QPID-7977
 URL: https://issues.apache.org/jira/browse/QPID-7977
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Keith Wall


During the work of QPID-7832, it was noticed that there is a potential for the 
direct memory used for uncommitted messages to be leak when a node loses the 
mastership. 

The test that exposed the direct leak is: 
org.apache.qpid.server.store.berkeleydb.replication.MultiNodeTest#testLossOfMasterNodeCausesClientToFailover

I think the problem is this.  When mastership is lost, the underlying database 
operation fail.  For instance, the virtualhost that was master is rolling back 
open transactions.  This causes the messages that were committed to the store 
to be removed 
(org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.StoredBDBMessage#remove).
  The underlying database operation fails 
(org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java:1085), 
this prevents the direct memory associated with the messages from being 
released.

The operation of the group is unaffected, and there is no message loss.  The 
JVM should eventually release the direct memory itself.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-857) Router crash when ctrl-c on router that has a libwebsockets listener connected to a console

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209530#comment-16209530
 ] 

ASF subversion and git services commented on DISPATCH-857:
--

Commit 976bd25dd439d306b40a39ec0328038e32874189 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=976bd25 ]

DISPATCH-857 - Shut down HTTP server before the AMQP server.


> Router crash when ctrl-c on router that has a libwebsockets listener 
> connected to a console
> ---
>
> Key: DISPATCH-857
> URL: https://issues.apache.org/jira/browse/DISPATCH-857
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ernest Allen
>Assignee: Ted Ross
> Fix For: 1.0.0
>
>
> The router will core under the following circumstances:
> - checkout the latest proton and dispatch. build and install
> - start a router using qpid-dispatch/tests/config-1/A.conf (not as a daemon)
> - start a console by browsing to localhost:5673
> - after the console connects, ctrl-c out of the router
> ^C2017-10-16 14:54:36.776194 -0400 SERVER (notice) Shut Down
> 2017-10-16 14:54:36.776305 -0400 ROUTER_CORE (info) Router Core thread exited
> 2017-10-16 14:54:36.776639 -0400 SERVER (info) HTTP server thread exit
> 2017-10-16 14:54:36.776909 -0400 SERVER (info) Connection from 10.10.123.4 
> (to 0.0.0.0:5673) failed: amqp:connection:framing-error connection aborted
> qdrouterd: /home/eallen/qpid-dispatch/src/posix/threading.c:57: 
> sys_mutex_lock: Assertion `result == 0' failed.
> Aborted (core dumped)
> Since this only happens after a console has connected, it may be related to 
> DISPATCH-855 which causes the 0.8.0 router to crash after the console 
> connection unexpectedly closed.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-857) Router crash when ctrl-c on router that has a libwebsockets listener connected to a console

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved DISPATCH-857.
---
Resolution: Fixed

> Router crash when ctrl-c on router that has a libwebsockets listener 
> connected to a console
> ---
>
> Key: DISPATCH-857
> URL: https://issues.apache.org/jira/browse/DISPATCH-857
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ernest Allen
>Assignee: Ted Ross
> Fix For: 1.0.0
>
>
> The router will core under the following circumstances:
> - checkout the latest proton and dispatch. build and install
> - start a router using qpid-dispatch/tests/config-1/A.conf (not as a daemon)
> - start a console by browsing to localhost:5673
> - after the console connects, ctrl-c out of the router
> ^C2017-10-16 14:54:36.776194 -0400 SERVER (notice) Shut Down
> 2017-10-16 14:54:36.776305 -0400 ROUTER_CORE (info) Router Core thread exited
> 2017-10-16 14:54:36.776639 -0400 SERVER (info) HTTP server thread exit
> 2017-10-16 14:54:36.776909 -0400 SERVER (info) Connection from 10.10.123.4 
> (to 0.0.0.0:5673) failed: amqp:connection:framing-error connection aborted
> qdrouterd: /home/eallen/qpid-dispatch/src/posix/threading.c:57: 
> sys_mutex_lock: Assertion `result == 0' failed.
> Aborted (core dumped)
> Since this only happens after a console has connected, it may be related to 
> DISPATCH-855 which causes the 0.8.0 router to crash after the console 
> connection unexpectedly closed.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (DISPATCH-857) Router crash when ctrl-c on router that has a libwebsockets listener connected to a console

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross reassigned DISPATCH-857:
-

Assignee: Ted Ross  (was: Ganesh Murthy)

> Router crash when ctrl-c on router that has a libwebsockets listener 
> connected to a console
> ---
>
> Key: DISPATCH-857
> URL: https://issues.apache.org/jira/browse/DISPATCH-857
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ernest Allen
>Assignee: Ted Ross
> Fix For: 1.0.0
>
>
> The router will core under the following circumstances:
> - checkout the latest proton and dispatch. build and install
> - start a router using qpid-dispatch/tests/config-1/A.conf (not as a daemon)
> - start a console by browsing to localhost:5673
> - after the console connects, ctrl-c out of the router
> ^C2017-10-16 14:54:36.776194 -0400 SERVER (notice) Shut Down
> 2017-10-16 14:54:36.776305 -0400 ROUTER_CORE (info) Router Core thread exited
> 2017-10-16 14:54:36.776639 -0400 SERVER (info) HTTP server thread exit
> 2017-10-16 14:54:36.776909 -0400 SERVER (info) Connection from 10.10.123.4 
> (to 0.0.0.0:5673) failed: amqp:connection:framing-error connection aborted
> qdrouterd: /home/eallen/qpid-dispatch/src/posix/threading.c:57: 
> sys_mutex_lock: Assertion `result == 0' failed.
> Aborted (core dumped)
> Since this only happens after a console has connected, it may be related to 
> DISPATCH-855 which causes the 0.8.0 router to crash after the console 
> connection unexpectedly closed.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7799) Broker should be able to write a periodic dump of statistics

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209483#comment-16209483
 ] 

Alex Rudyy commented on QPID-7799:
--

Keith,
Changes in [ 
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=51764e7 ] and [ 
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4cfa7c3 ] look 
good to me. However, I implemented some minor fixes and improvements in [ 
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=cec1954 ] and [ 
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=06a3072 ]. 
Additionally, I modified configuration store upgraders (for broker abd VH) in [ 
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d253bea ]  to 
upgrade the statistics settings from 6.1 to 7.0. Please, review

> Broker should be able to write a periodic dump of statistics
> 
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7799-Java-Broker-Improve-statistics-reporting.patch
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7913) [Java Broker] Improve message recovery logging

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-7913:
-
Status: Reviewable  (was: In Progress)

> [Java Broker] Improve message recovery logging
> --
>
> Key: QPID-7913
> URL: https://issues.apache.org/jira/browse/QPID-7913
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7913-Java-Broker-Log-a-single-warning-per-queue.patch
>
>
> Qpid broker message store recoverer generates a warning for every discarded 
> message as below
> {noformat}
> WARN  [VirtualHostNode-default-Config] 
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1183 in log 
> references queue with id de12d20b-bf6c-4d7b-a216-f613ee0635ae which is not in 
> the configuration, entry will be discarded
> {noformat}
> Potentially, the logging can be improved to generate a single log entry per 
> queue rather that per each message, where a number of discarded messages and 
> their ids can be reported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-7913) [Java Broker] Improve message recovery logging

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-7913:


Assignee: Alex Rudyy

> [Java Broker] Improve message recovery logging
> --
>
> Key: QPID-7913
> URL: https://issues.apache.org/jira/browse/QPID-7913
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7913-Java-Broker-Log-a-single-warning-per-queue.patch
>
>
> Qpid broker message store recoverer generates a warning for every discarded 
> message as below
> {noformat}
> WARN  [VirtualHostNode-default-Config] 
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1183 in log 
> references queue with id de12d20b-bf6c-4d7b-a216-f613ee0635ae which is not in 
> the configuration, entry will be discarded
> {noformat}
> Potentially, the logging can be improved to generate a single log entry per 
> queue rather that per each message, where a number of discarded messages and 
> their ids can be reported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved DISPATCH-829.
---
Resolution: Fixed

> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209452#comment-16209452
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 3fd09218c5903cab840eb048a209edc90bf99d5d 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=3fd0921 ]

DISPATCH-829 - Added a test for the abort capabilities (requires proton PR #123)


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209458#comment-16209458
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit fea60bc83210ab5ae714f346b4209f27fc807139 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=fea60bc ]

DISPATCH-829 - Added a multicast-truncated test


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209460#comment-16209460
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit b887c9e9fdc6251021acaa09ddcffd360319d318 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=b887c9e ]

DISPATCH-829 - Per Chuck Rolke's suggestion, grouped bool elements together in 
message structures.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209454#comment-16209454
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 653ed7c9249241ebddf3d21e26d89cc005fa 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=653ed7c ]

DISPATCH-829 - Handle truncated messages on routed links.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209455#comment-16209455
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 9871fdbfccb749c410a9f5d2ed9784e542026233 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=9871fdb ]

DISPATCH-829 - Added labels and debug logs to diagnose delivery ref-count 
issues.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209459#comment-16209459
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 956a5159942db179a4dd8325502e1287ebae1971 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=956a515 ]

DISPATCH-829 - Fixed delivey leak in multicast no-path case.  Removed spurious 
TODO.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209457#comment-16209457
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 83a0b70e41a4056c90a6e665f3372259be48851e 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=83a0b70 ]

DISPATCH-829 - Resolved the delivery under-counting problem.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209456#comment-16209456
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit bb62ac7089f20410a1c7bbd01b769e73a0d594fd 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=bb62ac7 ]

DISPATCH-829 - Changed the way delivery ref-counts are accounted for with 
respect to pn_delivery references to qdr_deliveries.
Note: I moved alloh*.h from src to include/qpid/dispatch.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-829) The router does not set the "aborted" indication on truncated, streamed deliveries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209453#comment-16209453
 ] 

ASF subversion and git services commented on DISPATCH-829:
--

Commit 294baf3729766ecaf1874963e466b40918e56b5a 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=294baf3 ]

DISPATCH-829 - Abort only deliveries that are not receive-complete. Push out 
undelivered messages on inbound-link-close.


> The router does not set the "aborted" indication on truncated, streamed 
> deliveries
> --
>
> Key: DISPATCH-829
> URL: https://issues.apache.org/jira/browse/DISPATCH-829
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 1.0.0
>
>
> Dispatch Router neither honors nor sets the aborted flag in deliveries.  Now 
> that Proton supports this flag and Dispatch Router supports large-message 
> streaming, this is a bug that needs to be fixed.
> There are two primary cases:
> # A streaming delivery is passing through the router when the sender's 
> connection/session/link drops mid-delivery.  The router _must_ set the 
> aborted flag on the outbound delivery so that the receiving container will 
> know that the delivery is no good.
> # A delivery arrives on the router with the aborted flag set.  It _must_ 
> either drop the delivery (if it has not yet been forwarded) or propagate the 
> aborted flag (if earlier frames of the delivery have already been forwarded).
> Please note that in a multi-router network, both of the above cases can occur 
> on the same message.  If the sender drops before completing the delivery, the 
> ingress router must handle case 1.  Downstream routers handling the delivery 
> will experience case 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #211: A pull request with Ganesh's, Chuck's, and ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/211


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1625) [c, examples] receiver does not dispose of aborted message data

[Chuck Rolke (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209448#comment-16209448
 ] 

Chuck Rolke commented on PROTON-1625:
-

The original commit was misguided and caused a memory leak.

> [c, examples] receiver does not dispose of aborted message data
> ---
>
> Key: PROTON-1625
> URL: https://issues.apache.org/jira/browse/PROTON-1625
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: proton-c-0.18.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1625) [c, examples] receiver does not dispose of aborted message data

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209442#comment-16209442
 ] 

ASF subversion and git services commented on PROTON-1625:
-

Commit 8d062b75376d350543a2ba0bc3b581c7f75757db in qpid-proton's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8d062b7 ]

Revert "PROTON-1625: flush received data from aborted messages"

This reverts commit b9d64d66c2851e005279fa78f770eed75407536d.


> [c, examples] receiver does not dispose of aborted message data
> ---
>
> Key: PROTON-1625
> URL: https://issues.apache.org/jira/browse/PROTON-1625
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: proton-c-0.18.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (PROTON-1638) Need to improve proton-c build tree layout

[Andrew Stitcher (JIRA)]

Andrew Stitcher created PROTON-1638:
---

 Summary: Need to improve proton-c build tree layout
 Key: PROTON-1638
 URL: https://issues.apache.org/jira/browse/PROTON-1638
 Project: Qpid Proton
  Issue Type: Improvement
Affects Versions: proton-c-0.18.0
Reporter: Andrew Stitcher


The proton-c tree layout is annoying in a number of ways:

* Since the split with proton-j there is a superfluous top level
* CMake build flags don't propagate properly because examples are not in the 
correct subtree
** Examples should be in the binding subtree that they are examples
** Otherwise the information for a particular binding and its examples are 
split into 2 different parts of the proton-c tree.
** This means that the installation for a binding is split
** It is unatural in CMake to split build flags like this - CMake is 
hierarchical



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Adel Boutros (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209428#comment-16209428
 ] 

Adel Boutros edited comment on QPID-7973 at 10/18/17 2:36 PM:
--

Hello [~k-wall],

When I did the fix on [QPID-7974| 
https://issues.apache.org/jira/browse/QPID-7974]. Some unit tests failed. When 
I looked, the testing were appending "null" to the table names. This was 
because setTableNamePrefix was being called with a null tablePrefix and as all 
tables have "tablePrefix + TableName".

Test failing: 
org.apache.qpid.server.store.jdbc.GenericJDBCConfigurationStoreTest

Error (See how table name contains NULL): Caused by: java.sql.SQLException: 
Table/View 'NULLQPID_CONFIGURED_OBJECTS' already exists in Schema 'APP'.


was (Author: adelbout...@live.com):
Hello [~k-wall],

When I did the fix on [QPID-7974| 
https://issues.apache.org/jira/browse/QPID-7974]. Some unit tests failed. When 
I looked, the testing were appending "null" to the table names. This was 
because setTableNamePrefix was being called with a null tablePrefix and as all 
tables have "tablePrefix + TableName".

Test failing: 
org.apache.qpid.server.store.jdbc.GenericJDBCConfigurationStoreTest

Error (See how table name contains NULL: Caused by: java.sql.SQLException: 
Table/View 'NULLQPID_CONFIGURED_OBJECTS' already exists in Schema 'APP'.

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Adel Boutros (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209428#comment-16209428
 ] 

Adel Boutros commented on QPID-7973:


Hello [~k-wall],

When I did the fix on [QPID-7974| 
https://issues.apache.org/jira/browse/QPID-7974]. Some unit tests failed. When 
I looked, the testing were appending "null" to the table names. This was 
because setTableNamePrefix was being called with a null tablePrefix and as all 
tables have "tablePrefix + TableName".

Test failing: 
org.apache.qpid.server.store.jdbc.GenericJDBCConfigurationStoreTest

Error (See how table name contains NULL: Caused by: java.sql.SQLException: 
Table/View 'NULLQPID_CONFIGURED_OBJECTS' already exists in Schema 'APP'.

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1633) Windows Link warnings due to unnecessary command line flags

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209427#comment-16209427
 ] 

ASF subversion and git services commented on PROTON-1633:
-

Commit 89c8b5fa0b4f529b3e2c27434c02f29a7afdaac0 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=89c8b5f ]

PROTON-1633: Need to allow examples to link with special flags to get 
sanitizers to work


> Windows Link warnings due to unnecessary command line flags
> ---
>
> Key: PROTON-1633
> URL: https://issues.apache.org/jira/browse/PROTON-1633
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: Visual Studio
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> We are explicitly putting compile flags on the link line and this is 
> generating pointless and distracting warnings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209413#comment-16209413
 ] 

Keith Wall commented on QPID-7973:
--

Hi Adel,  how are you running into this defect?  The {{tableNamePrefix}} gets 
assigned an empty string default at the JDBCVirtualHost and JDBCVirtualHostNode 
level, so I don't understand why your change is required.  See 
org/apache/qpid/server/virtualhost/jdbc/JDBCVirtualHost.java:47)=.  The 
decision to apply defaults at a single point in the abstraction is a deliberate 
one, so I don't understand why we need a special case here.   

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209407#comment-16209407
 ] 

ASF subversion and git services commented on QPID-7974:
---

Commit 955a79b7dfde570dc7d7a6cc9d89b2e6dd1ff137 in qpid-broker-j's branch 
refs/heads/master from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=955a79b ]

QPID-7974 : Fix the logic I broker in Adel's commit


> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7976) [Java Broker] Asynchronous message store recoverer does not delete message instances for unknown queues

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-7976:


 Summary: [Java Broker] Asynchronous message store recoverer does 
not delete message instances for unknown queues
 Key: QPID-7976
 URL: https://issues.apache.org/jira/browse/QPID-7976
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0
Reporter: Alex Rudyy


Asynchronous message store recoverer does not clean up message instances for 
unknown queues. As result message store can grow in size indefinitely. The 
issue can occur in the following scenarios;
* when queue with enqueued messages is manually deleted from the configuration 
store
* when {{MessageDurability#ALWAYS}} is configured on non-durable queue and 
broker is restarted with messages on the queue
* when persistent message is enqueued into non durable queue (temp queue) and 
broker is restarted with messages on the queue

The work around is to use "Synchronous message store recoverer" (configured by 
default)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Lorenz Quack (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209395#comment-16209395
 ] 

Lorenz Quack commented on QPID-7974:


I just had a very brief look but the commit seems wrong.
It looks like if the tableName is all lower or all upper case tableExists will 
always return true regardless of whether the table exists or not.

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch issue #211: A pull request with Ganesh's, Chuck's, and my upda...

[ganeshmurthy]

Github user ganeshmurthy commented on the issue:

https://github.com/apache/qpid-dispatch/pull/211
  
Ship It!


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #211: A pull request with Ganesh's, Chuck's, and ...

[ChugR]

Github user ChugR commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/211#discussion_r145424345
  
--- Diff: src/message_private.h ---
@@ -113,6 +113,7 @@ typedef struct {
 bool receive_complete;   // true if the 
message has been completely received, false otherwise
 sys_atomic_t fanout; // The number of 
receivers for this message. This number does not include in-process subscribers.
 bool q2_input_holdoff;   // hold off 
calling pn_link_recv
+bool aborted;// receive 
completed with abort flag set
--- End diff --

For performance with smaller cache use it would make sense to group the 
bools together and not split them with elements that have alignment 
requirements.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209366#comment-16209366
 ] 

ASF subversion and git services commented on QPID-7975:
---

Commit 9b3014adcbd65fedfba9ba4f6797fc46cbb0062f in qpid-cpp's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=9b3014a ]

QPID-7975: Fix for InactivityFireEvent state machine


> [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently 
> causes high latency for 1.0 messages
> 
>
> Key: QPID-7975
> URL: https://issues.apache.org/jira/browse/QPID-7975
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>
> When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
> concurrently, a condition is triggered where the store no longer flushes the 
> 1.0 messages. When this condition is triggered, the 1.0 messages are flushed 
> by the 0-10 activity on the queue, or if there is none, then the messages are 
> never flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7913) [Java Broker] Improve message recovery logging

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209363#comment-16209363
 ] 

ASF subversion and git services commented on QPID-7913:
---

Commit fa9f46abfc2206f07054d1ec111f9c43aea494e2 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fa9f46a ]

QPID-7913: [Java Broker] Log warning with aggregated details for all orphan 
messages and unused messages instances per queue


> [Java Broker] Improve message recovery logging
> --
>
> Key: QPID-7913
> URL: https://issues.apache.org/jira/browse/QPID-7913
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7913-Java-Broker-Log-a-single-warning-per-queue.patch
>
>
> Qpid broker message store recoverer generates a warning for every discarded 
> message as below
> {noformat}
> WARN  [VirtualHostNode-default-Config] 
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1183 in log 
> references queue with id de12d20b-bf6c-4d7b-a216-f613ee0635ae which is not in 
> the configuration, entry will be discarded
> {noformat}
> Potentially, the logging can be improved to generate a single log entry per 
> queue rather that per each message, where a number of discarded messages and 
> their ids can be reported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7799) Broker should be able to write a periodic dump of statistics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209359#comment-16209359
 ] 

ASF subversion and git services commented on QPID-7799:
---

Commit cec195436a4547cff7c652d4689faf902942b818 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=cec1954 ]

QPID-7799: [Java Broker] Fix typos and improve documentation for statistics 
reporting


> Broker should be able to write a periodic dump of statistics
> 
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7799-Java-Broker-Improve-statistics-reporting.patch
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7799) Broker should be able to write a periodic dump of statistics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209362#comment-16209362
 ] 

ASF subversion and git services commented on QPID-7799:
---

Commit d253bea18fb976ec7868e12e1867698211a51afb in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d253bea ]

QPID-7799: [Java Broker] Modify broker and virtual host store upgraders to add 
statistics related context variables and logging rules


> Broker should be able to write a periodic dump of statistics
> 
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7799-Java-Broker-Improve-statistics-reporting.patch
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7799) Broker should be able to write a periodic dump of statistics

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209361#comment-16209361
 ] 

ASF subversion and git services commented on QPID-7799:
---

Commit 06a30729357dce56da9c27c0aa252eed1b7388df in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=06a3072 ]

QPID-7799: [Java Broker] Remove duplicate code


> Broker should be able to write a periodic dump of statistics
> 
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7799-Java-Broker-Improve-statistics-reporting.patch
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209352#comment-16209352
 ] 

Kim van der Riet commented on QPID-7975:


The problem lies again with the {{linearstore::journal::InactivityFireEvent}} 
class.  The state machine in this {{TimerTask}} child class is getting stuck 
because no path was added for the class to move from state {{FLUSHED}} to state 
{{FIRED}} for cases where an external flush call (as provided by the AMQP 0-10 
messages) arrives before a timer fire.  This prevented the timer from being 
reset and from firing in the normal manner.

> [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently 
> causes high latency for 1.0 messages
> 
>
> Key: QPID-7975
> URL: https://issues.apache.org/jira/browse/QPID-7975
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>
> When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
> concurrently, a condition is triggered where the store no longer flushes the 
> 1.0 messages. When this condition is triggered, the 1.0 messages are flushed 
> by the 0-10 activity on the queue, or if there is none, then the messages are 
> never flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209346#comment-16209346
 ] 

Kim van der Riet commented on QPID-7975:


Pavel's reproducer:

Smaller reproducer using just one queue:

1) In one terminal, run below cmds in a script:

{noformat}
rm -rf /var/lib/qpidd/*
killall qpid-send qpid-receive
service qpidd restart

# create durable queue
qpid-receive -a "DurablePerf; {create:always, node:{type:queue, durable:true}}"

# have 1.0 consumer forever
qpid-receive -a DurablePerf -m 100 --print-content=no --print-headers=no 
--connection-options "{protocol:'amqp1.0'}" --capacity=1 -f &

# repeatedly send a 1.0 message and print real time spent there
while true; do
(time qpid-send -a DurablePerf --capacity=1 --durable=yes -m 1 
--content-size=$((RANDOM%500+1000)) --connection-options 
"{protocol:'amqp1.0'}") 2>&1 | grep real
sleep 1
done &
{noformat}


2) In another terminal, send some 0-10 messages time to time to the same queue:

{noformat}
while true; do
qpid-send -a DurablePerf --capacity=1 --durable=yes -m 10 
--content-size=$((RANDOM%1500))
sleep 1
ps aux | grep -v grep | grep qpid-send
sleep 1
ps aux | grep -v grep | grep qpid-send
date
done
{noformat}

3) check 1st terminal output - "real" time (how long does it take each 
qpid-send to send a message and terminate) will be below 0.1s. But after a race 
condition is hit (concurrent sending 0-10 and 1.0 message?), the times start to 
be above 1s forever.

Since that time, 2nd terminal will show:

{noformat}
Tue Oct 17 12:17:30 CEST 2017
root 21615  0.0  0.0 202836  5636 pts/1Sl   12:17   0:00 qpid-send -a 
DurablePerf --capacity=1 --durable=yes -m 1 --content-size=1206 
--connection-options {protocol:'amqp1.0'}
root 21615  0.0  0.0 202836  5636 pts/1Sl   12:17   0:00 qpid-send -a 
DurablePerf --capacity=1 --durable=yes -m 1 --content-size=1206 
--connection-options {protocol:'amqp1.0'}
Tue Oct 17 12:17:33 CEST 2017
root 21632  0.0  0.0 202836  5640 pts/1Sl   12:17   0:00 qpid-send -a 
DurablePerf --capacity=1 --durable=yes -m 1 --content-size=1327 
--connection-options {protocol:'amqp1.0'}
root 21632  0.0  0.0 202836  5640 pts/1Sl   12:17   0:00 qpid-send -a 
DurablePerf --capacity=1 --durable=yes -m 1 --content-size=1327 
--connection-options {protocol:'amqp1.0'}
Tue Oct 17 12:17:35 CEST 2017
{noformat}

i.e. same qpid-send (compare PID) after 1 second sleep.


> [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently 
> causes high latency for 1.0 messages
> 
>
> Key: QPID-7975
> URL: https://issues.apache.org/jira/browse/QPID-7975
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>
> When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
> concurrently, a condition is triggered where the store no longer flushes the 
> 1.0 messages. When this condition is triggered, the 1.0 messages are flushed 
> by the 0-10 activity on the queue, or if there is none, then the messages are 
> never flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #211: A pull request with Ganesh's, Chuck's, and ...

[ganeshmurthy]

Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/211#discussion_r145415389
  
--- Diff: src/message.c ---
@@ -1407,6 +1410,17 @@ void qd_message_send(qd_message_t *in_msg,
 
 if (msg->sent_depth < QD_DEPTH_MESSAGE_ANNOTATIONS) {
 
+if (msg->content->aborted) {
+// Message is aborted before any part of it has been sent.
+// Declare the message to be sent,
+msg->send_complete = true;
+// the link has an outgoing deliver. abort it.
+pn_delivery_abort(pn_link_current(pnl));
+
+// TODO: Dispose of message buffers that may have accumulated
--- End diff --

Can we remove this TODO since the buffers are eventually freed when the 
message is freed?


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[Kim van der Riet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kim van der Riet updated QPID-7975:
---
Description: When durable messages are sent to the same queue using both 
AMQP 1.0 and 0-10 concurrently, a condition is triggered where the store no 
longer flushes the 1.0 messages. When this condition is triggered, the 1.0 
messages are flushed by the 0-10 activity on the queue, or if there is none, 
then the messages are never flushed.  (was: When durable messages are sent to 
the same queue using both AMQP 1.0 and 0-10 concurrently, a condition is 
triggered where the store no longer flushes the 1.0 messages. When this 
condition is triggered, the 1.0 messages are flushed by the 0-10 activity on 
the queue, or if there is none, then the messages are never flushed.

A reproducer is shown in https://bugzilla.redhat.com/show_bug.cgi?id=1502885.)

> [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently 
> causes high latency for 1.0 messages
> 
>
> Key: QPID-7975
> URL: https://issues.apache.org/jira/browse/QPID-7975
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>
> When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
> concurrently, a condition is triggered where the store no longer flushes the 
> 1.0 messages. When this condition is triggered, the 1.0 messages are flushed 
> by the 0-10 activity on the queue, or if there is none, then the messages are 
> never flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7975) [linearstore] Sending durable messages using AMQP 1.0 and 0-10 concurrently causes high latency for 1.0 messages

[Kim van der Riet (JIRA)]

Kim van der Riet created QPID-7975:
--

 Summary: [linearstore] Sending durable messages using AMQP 1.0 and 
0-10 concurrently causes high latency for 1.0 messages
 Key: QPID-7975
 URL: https://issues.apache.org/jira/browse/QPID-7975
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Reporter: Kim van der Riet


When durable messages are sent to the same queue using both AMQP 1.0 and 0-10 
concurrently, a condition is triggered where the store no longer flushes the 
1.0 messages. When this condition is triggered, the 1.0 messages are flushed by 
the 0-10 activity on the queue, or if there is none, then the messages are 
never flushed.

A reproducer is shown in https://bugzilla.redhat.com/show_bug.cgi?id=1502885.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned QPID-7973:
-

Assignee: Rob Godfrey

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7974:
--
Fix Version/s: qpid-java-broker-7.0.0

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7973:
--
Fix Version/s: qpid-java-broker-7.0.0

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7974:
--
Status: Reviewable  (was: In Progress)

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7973:
--
Status: Reviewable  (was: In Progress)

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned QPID-7974:
-

Assignee: Rob Godfrey

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209304#comment-16209304
 ] 

ASF subversion and git services commented on QPID-7974:
---

Commit 3a6bb20dc037a88d528045eae4bcc2daacf955ae in qpid-broker-j's branch 
refs/heads/master from aboutros
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3a6bb20 ]

QPID-7974: Only search for the needed table instead of querying the whole 
database tables
This closes #3


> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209305#comment-16209305
 ] 

ASF GitHub Bot commented on QPID-7974:
--

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-broker-j/pull/3


> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #211: A pull request with Ganesh's, Chuck's, and ...

[ted-ross]

GitHub user ted-ross opened a pull request:

https://github.com/apache/qpid-dispatch/pull/211

A pull request with Ganesh's, Chuck's, and my updates for abort handling



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ted-ross/qpid-dispatch tross-DISPATCH-829-2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/211.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #211


commit 4be95cd6beb4f9f1f3b9cc402be9322a07da8a9d
Author: Chuck Rolke 
Date:   2017-09-28T14:35:45Z

DISPATCH-829: Sense messages received with abort status.

commit a1726fac6b8720476c66e908e4526a4f507f0952
Author: Chuck Rolke 
Date:   2017-10-02T20:06:57Z

DISPATCH-829: handle aborted messages

commit 5630becc56002bcb67502bead6f5da07d80078b2
Author: Ganesh Murthy 
Date:   2017-10-05T21:59:01Z

DISPATCH-829 - Added a proton_ref set flag so we can incref and decref 
accordingly

commit f5d1a77d61ce9e1662f4945273d4f7beeefb5e1b
Author: Ganesh Murthy 
Date:   2017-10-06T18:48:33Z

DISPATCH-829 - Added code to abort delivery on link cleanup

commit 90a8b62ff561348438aea4035c4ad7027f64232d
Author: Chuck Rolke 
Date:   2017-10-09T15:24:16Z

DISPATCH-829: outbound aborted messages must be marked send_complete

commit 3fd09218c5903cab840eb048a209edc90bf99d5d
Author: Ted Ross 
Date:   2017-10-10T18:27:37Z

DISPATCH-829 - Added a test for the abort capabilities (requires proton PR 
#123)

commit 294baf3729766ecaf1874963e466b40918e56b5a
Author: Ted Ross 
Date:   2017-10-10T18:28:55Z

DISPATCH-829 - Abort only deliveries that are not receive-complete. Push 
out undelivered messages on inbound-link-close.

commit 653ed7c9249241ebddf3d21e26d89cc005fa
Author: Ted Ross 
Date:   2017-10-11T16:39:43Z

DISPATCH-829 - Handle truncated messages on routed links.

commit 9871fdbfccb749c410a9f5d2ed9784e542026233
Author: Ted Ross 
Date:   2017-10-16T17:10:43Z

DISPATCH-829 - Added labels and debug logs to diagnose delivery ref-count 
issues.

commit b1c88114b40827f68a3d407bea802097190385d1
Author: Ted Ross 
Date:   2017-10-16T17:11:34Z

NO-JIRA - Added a pointer check-before-dereference in container.c

commit bb62ac7089f20410a1c7bbd01b769e73a0d594fd
Author: Ted Ross 
Date:   2017-10-17T17:55:58Z

DISPATCH-829 - Changed the way delivery ref-counts are accounted for with 
respect to pn_delivery references to qdr_deliveries.
Note: I moved alloh*.h from src to include/qpid/dispatch.

commit 83a0b70e41a4056c90a6e665f3372259be48851e
Author: Ted Ross 
Date:   2017-10-17T19:32:48Z

DISPATCH-829 - Resolved the delivery under-counting problem.

commit fea60bc83210ab5ae714f346b4209f27fc807139
Author: Ted Ross 
Date:   2017-10-18T13:07:19Z

DISPATCH-829 - Added a multicast-truncated test




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j pull request #3: QPID-7974: Only search for the needed table i...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-broker-j/pull/3


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209270#comment-16209270
 ] 

ASF subversion and git services commented on QPID-7973:
---

Commit d68c897052ca3e7a07f7ca4fccfd1f4d6832b6d7 in qpid-broker-j's branch 
refs/heads/master from aboutros
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d68c897 ]

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided instead of 
empty String
This closes #2


> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209271#comment-16209271
 ] 

ASF GitHub Bot commented on QPID-7973:
--

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-broker-j/pull/2


> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j pull request #2: QPID-7973: Table Name Prefix is set to NULL i...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-broker-j/pull/2


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Adel Boutros (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209262#comment-16209262
 ] 

Adel Boutros commented on QPID-7974:


[~rgodfrey] Done :)

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209261#comment-16209261
 ] 

ASF GitHub Bot commented on QPID-7974:
--

GitHub user adel-boutros opened a pull request:

https://github.com/apache/qpid-broker-j/pull/3

QPID-7974: Only search for the needed table instead of querying the w…

QPID-7974: Only search for the needed table instead of querying the whole 
database tables

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adel-boutros/qpid-broker-j 
fix_jdbc_table_exist

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-broker-j/pull/3.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3


commit 78c5d25c2ed79751e7456467178213a0585f1f5a
Author: aboutros 
Date:   2017-10-18T12:41:42Z

QPID-7974: Only search for the needed table instead of querying the whole 
database tables




> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j pull request #3: QPID-7974: Only search for the needed table i...

[adel-boutros]

GitHub user adel-boutros opened a pull request:

https://github.com/apache/qpid-broker-j/pull/3

QPID-7974: Only search for the needed table instead of querying the w…

QPID-7974: Only search for the needed table instead of querying the whole 
database tables

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adel-boutros/qpid-broker-j 
fix_jdbc_table_exist

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-broker-j/pull/3.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3


commit 78c5d25c2ed79751e7456467178213a0585f1f5a
Author: aboutros 
Date:   2017-10-18T12:41:42Z

QPID-7974: Only search for the needed table instead of querying the whole 
database tables




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j issue #1: Jdbc fixes

[adel-boutros]

Github user adel-boutros commented on the issue:

https://github.com/apache/qpid-broker-j/pull/1
  
Will separate them into 2 different PRs


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j pull request #1: Jdbc fixes

[adel-boutros]

Github user adel-boutros closed the pull request at:

https://github.com/apache/qpid-broker-j/pull/1


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209253#comment-16209253
 ] 

ASF GitHub Bot commented on QPID-7973:
--

GitHub user adel-boutros opened a pull request:

https://github.com/apache/qpid-broker-j/pull/2

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adel-boutros/qpid-broker-j fix_table_prefix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-broker-j/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit 216a820f9eb6b300e3dd8c30c2f8dd57698496ae
Author: aboutros 
Date:   2017-10-18T10:34:14Z

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided 
instead of empty String




> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-broker-j pull request #2: QPID-7973: Table Name Prefix is set to NULL i...

[adel-boutros]

GitHub user adel-boutros opened a pull request:

https://github.com/apache/qpid-broker-j/pull/2

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adel-boutros/qpid-broker-j fix_table_prefix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-broker-j/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit 216a820f9eb6b300e3dd8c30c2f8dd57698496ae
Author: aboutros 
Date:   2017-10-18T10:34:14Z

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided 
instead of empty String




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209246#comment-16209246
 ] 

Rob Godfrey commented on QPID-7974:
---

[~adelbout...@live.com] That would be good - thx.  Also, in terms of PRs, it's 
generally better to raise a separate PR for each JIRA and to have the JIRA id 
in the PR comment as this should then automagically link the PR and the JIRA I 
think.

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Adel Boutros (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209231#comment-16209231
 ] 

Adel Boutros commented on QPID-7974:


Your idea is excellent!
It is still a lot faster to do 3 simple queries than to wait for all of them.

Do you want me to do the change on the pull request?
# check all upper case
# fallback to check all lower case
# fallback to check without changing case

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org