0.18 release update - RC2 is out

[Justin Ross]

Hi, everyone.  I've produced RC2 at revision 1368514.  Get it here:

  http://people.apache.org/~jross/qpid-0.18-rc2/

I'm going to be away on vacation until the 13th of August.  If no changes are 
requested before then, I'll propose RC2 (after I've signed it) for our release 
vote when I return.

If, however, there are requests for inclusion while I'm away, I'd like to ask 
Robbie to handle those approvals.

Thanks is due to Alex, Darryl, and Keith for testing RC1 and reporting their 
findings.

Thanks!
Justin

---
0.18 release page: https://cwiki.apache.org/qpid/018-release.html

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

Address: Name cannot be null

[Darryl L. Pierce]

I've written the initial Perl language bindings on top of what Swig
gives us in Qpid. I'm now porting the examples in
cpp/bindings/qpid/examples/perl over to use the newer code but am
hitting this weird problem. (code can be found here [1])

In the client/server examples, things start up nicely:

1. start a test instance of qpidd --auth=no
2. start server.pl
3. start client.pl

It's on step #3 above that I see, in the server.pl window, the following
error message:

Name cannot be null at 
/home/mcpierce/Programming/Qpid/qpid/cpp/bindings/qpid/perl/qpid.pm line 666.
2012-08-02 17:11:52 [Client] warning Connection 
[127.0.0.1:33410-127.0.0.1:5672] closed

In qpid.pm the code in question (line 666, how ominous) is in
qpid::Session:

656: sub create_sender {
657: my ($self) = @_;
658: my $impl = $self->{_impl};
659:
660: my $address = $_[1];
661:
662: if (ref($address) eq "qpid::Address") {
663: my $temp = $address->get_implementation();
664: $address = $temp;
665: }
666: my $send_impl = $impl->createSender($address);
667:
668: return new qpid::Sender($send_impl, $self);
669: }

And debugging this I see that indeed $address (which is an instance of
cqpid_perl::Address) in fact does *not* have a name. The sender is being
created by the following code in server.pl:

while (1) {
my $request = $receiver->fetch();
my $address = $request->get_reply_to();
if ($address) {

# RIGHT HERE
my $sender = $session->create_sender($address);

my $s = $request->get_content();
$s = uc($s);
my $response = new qpid::Message($s);
$sender->send($response);
print "Processed request: " . $request->get_content() . " -> " . 
$response->get_content() . "\n";
$session->acknowledge();
}
else {
print "Error: no reply address specified for request: " . 
$request->get_content() . "\n";
$session->reject($request);
}
}

I'm at a loss how, if a name is required for an address, this instance
of address is arriving without a name. Or is the Perl example outdated
and I'm missing something?

[1] https://github.com/mcpierce/Qpid/tree/Perl-language-bindings

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpPuRzMB64I4.pgp
Description: PGP signature

[jira] [Updated] (QPID-4178) qpidd refactor

[Gordon Sim (JIRA)]

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

Gordon Sim updated QPID-4178:
-

Attachment: refactor_store_impact.patch

Slight tweak to previous patch, avoiding unintentional commenting out of 
subdirs for tests.

> qpidd refactor
> --
>
> Key: QPID-4178
> URL: https://issues.apache.org/jira/browse/QPID-4178
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.19
>
> Attachments: refactor_store_impact.patch, refactor_store_impact.patch
>
>
> == Background ==
> I've been looking at what would be required to get AMQP 1.0 support in
> the qpidd broker (using proton-c). In that context I felt there was a
> need to refactor the broker code, particularly that part that would be
> shared between different protocol versions. Part of the motivation was
> clearer separation of 0-10 specific logic, so that 1.0 logic could be
> introduced as an alternative. However part of it was also simply the
> recognition of some long-standing problems that we have never stopped
> to address.
> So, here is a patch representing my ideas on what is needed. This is
> a little stale again (patch was generated against r13613342) and
> needs (yet) another rebase. However it is getting to the point where I'll be 
> asking to commit it soon, so if anyone has feedback, now is the time to give 
> it!
> == Key Changes ==
> qpid::broker::Message
> This is now supposed to be a protocol neutral representation of a
> message. It no longer exposes qpid::framing::FrameSet. It can be based
> on data received in different encodings (this patch only includes the
> existing 0-10 encoding).
> The immutable, sharable state is separated from the mutable
> queue-specific state. Messages themselves are no longer held through a
> shared pointer but are passed by reference or copied if needed. The
> immutable state (essentially the data as received) *is* still shared
> and referenced internally through an intrusive pointer. There is no
> longer a message level lock. A message instance is 'owned' by
> someother entity (usually the queue it is on) which controls
> concurrent access/modification if necessary.
> The persistence context is a separate part of the message
> also. Currently that can be shared between two message instances if
> desired.
> qpid::broker::Messages
> Switched from using qpid::broker::QueuedMessage (which relied on
> shared pointer to message itself and made sequence number the explicit
> - and only - way to refer to a specific message) to using modified
> Message class directly and a new qpid::broker::QueueCursor.
> The cursor is opaque outside the Messages implementation to which it
> relates. It provides a way to refer to a specific message (without
> directly using sequence number, though at present that is what is used
> 'under the covers') and/or to track progress through a sequence of
> messages (for consumers or other iterating entities).
> I.e. its an iterator to a Message within its containing Messages
> instance that is not invalidated by changes to that container.
> A Messages instance *owns* the Message instances within it. Other
> classes access this through a reference or (raw) pointer, or if needed
> copy it (the immutable part can be - and is - safely shared).
> The codepath for browse/consume is a lot more unified now. You use a
> cursor and call Messages::next() in each case. This also lays the
> foundation for selectors.
> The simplified Messages interface led to a simplied
> MessageDistributor. There is still a little more to do to clarify
> these separate roles (or indeed perhaps unify them?) but more on that
> later.
> qpid::broker::amqp_0_10::MessageTransfer
> This represents the familiar 0-10 encoding of a message. This class is
> broadly similar to the old Message class, based on a FrameSet. However
> it represents the shared and essentially immutable state. The
> sendHeader() method now explicitly takes a copy of the original
> headers and adds to it or otherwise modifies it if needed (e.g. for
> redelivered flag, ttl, annotations etc).
> [Ideally I'd like to move more of the 0-10 specific classes out of
> qpid::broker and into qpid::broker::amqp_0_10, but that has no
> functional relevance so I've left existing classes alone for now.]
> qpid::broker::Consumer
> The deliver() method now takes a QueueCursor (representing a 'handle'
> to this message for use in subsequent operations such as accept,
> relese etc) and a *constant reference* to the Message itself
> (i.e. consumers can't alter the state of the message on the queue
> directly, but only through operations on the queue itself).
> qpid::broker::QueueRegistry
> The actual queue creation has been pulled out into a base class,
> QueueFactory. The

Re: Review Request: qpidd refactor

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5833/
---

(Updated Aug. 2, 2012, 9:17 p.m.)


Review request for qpid, Alan Conway and Kenneth Giusti.


Changes
---

One final missing export declaration for windows.


Description
---

== Background ==

I've been looking at what would be required to get AMQP 1.0 support in
the qpidd broker (using proton-c). In that context I felt there was a
need to refactor the broker code, particularly that part that would be
shared between different protocol versions. Part of the motivation was
clearer separation of 0-10 specific logic, so that 1.0 logic could be
introduced as an alternative. However part of it was also simply the
recognition of some long-standing problems that we have never stopped
to address.

So, here is a patch representing my ideas on what is needed. This is
a little stale again (patch was generated against r13613342) and
needs (yet) another rebase. However it is getting to the point where I'll be 
asking to commit it soon, so if anyone has feedback, now is the time to give it!

== Key Changes ==

qpid::broker::Message

This is now supposed to be a protocol neutral representation of a
message. It no longer exposes qpid::framing::FrameSet. It can be based
on data received in different encodings (this patch only includes the
existing 0-10 encoding).

The immutable, sharable state is separated from the mutable
queue-specific state. Messages themselves are no longer held through a
shared pointer but are passed by reference or copied if needed. The
immutable state (essentially the data as received) *is* still shared
and referenced internally through an intrusive pointer. There is no
longer a message level lock. A message instance is 'owned' by
someother entity (usually the queue it is on) which controls
concurrent access/modification if necessary.

The persistence context is a separate part of the message
also. Currently that can be shared between two message instances if
desired.

qpid::broker::Messages

Switched from using qpid::broker::QueuedMessage (which relied on
shared pointer to message itself and made sequence number the explicit
- and only - way to refer to a specific message) to using modified
Message class directly and a new qpid::broker::QueueCursor.

The cursor is opaque outside the Messages implementation to which it
relates. It provides a way to refer to a specific message (without
directly using sequence number, though at present that is what is used
'under the covers') and/or to track progress through a sequence of
messages (for consumers or other iterating entities).

I.e. its an iterator to a Message within its containing Messages
instance that is not invalidated by changes to that container.

A Messages instance *owns* the Message instances within it. Other
classes access this through a reference or (raw) pointer, or if needed
copy it (the immutable part can be - and is - safely shared).

The codepath for browse/consume is a lot more unified now. You use a
cursor and call Messages::next() in each case. This also lays the
foundation for selectors.

The simplified Messages interface led to a simplied
MessageDistributor. There is still a little more to do to clarify
these separate roles (or indeed perhaps unify them?) but more on that
later.

qpid::broker::amqp_0_10::MessageTransfer

This represents the familiar 0-10 encoding of a message. This class is
broadly similar to the old Message class, based on a FrameSet. However
it represents the shared and essentially immutable state. The
sendHeader() method now explicitly takes a copy of the original
headers and adds to it or otherwise modifies it if needed (e.g. for
redelivered flag, ttl, annotations etc).

[Ideally I'd like to move more of the 0-10 specific classes out of
qpid::broker and into qpid::broker::amqp_0_10, but that has no
functional relevance so I've left existing classes alone for now.]

qpid::broker::Consumer

The deliver() method now takes a QueueCursor (representing a 'handle'
to this message for use in subsequent operations such as accept,
relese etc) and a *constant reference* to the Message itself
(i.e. consumers can't alter the state of the message on the queue
directly, but only through operations on the queue itself).

qpid::broker::QueueRegistry

The actual queue creation has been pulled out into a base class,
QueueFactory. The actual class of the Queue returned can now be varied
and there are two subclasses in the current patch. The first is a
replacement for the ring policy logic, whereby messages are removed
from the queue in order to keep the queue from growing above a
configured limit. The second is for last value queues and simply pulls
the special case behaviour out of the common code path.

The handling of queue configuration has also been made cleaner and
more uniform, based on the QueueSettin

Re: What libraries/versions for proton?

[Darryl L. Pierce]

On Thu, Aug 02, 2012 at 04:48:42PM -0400, Joseph Ottinger wrote:
> It's Fedora 17, with a fairly clean install at that. Uuid and uuid-develop,
>  plus libuuid,  if memory serves, so as far as I can tell it should be
> pretty normal.

I should also mention (at least on Fedora systems) a way to find what's
required is with the "yum whatprovides" command. So, for example, in
this case you need /usr/include/uuid/uuid.h since the code is:

#include 

You can do:

sudo yum whatprovides */uuid/uuid.h

and yum will tell you the specific package(s) containing the file(s)
that match the provided mask.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpLPMZhyzTQI.pgp
Description: PGP signature

Re: What libraries/versions for proton?

[Darryl L. Pierce]

On Thu, Aug 02, 2012 at 04:48:42PM -0400, Joseph Ottinger wrote:
> It's Fedora 17, with a fairly clean install at that. Uuid and uuid-develop,
>  plus libuuid,  if memory serves, so as far as I can tell it should be
> pretty normal.

You need to have libuuid-devel, which provides the headers needed to
compile.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpC3NYq8aRiW.pgp
Description: PGP signature

Re: What libraries/versions for proton?

[Joseph Ottinger]

It's Fedora 17, with a fairly clean install at that. Uuid and uuid-develop,
 plus libuuid,  if memory serves, so as far as I can tell it should be
pretty normal.

On Thursday, August 2, 2012, Andrew Stitcher  wrote:
> On Thu, 2012-08-02 at 15:55 -0400, Joseph Ottinger wrote:
>> I was building proton-c and the build fails in messenger.c, trying to
>> include .
>>
>> There's a uuid library for C, but it defines different types than
>> proton is expecting. Can anyone tell me which uuid library is
>> expected? It's looking for a *system* library for uuid.
>
> You don't say which platform you are trying to build on. I'm guessing
> it's not Linux.
>
> The uuid functionality is irritatingly different between platforms. The
> current proton code compiles on Linux using libuuid libuuid-devel on
> Fedora and I think libuuid-dev on Debian based distros.
>
> On Solaris there is also uuid/uuid.h but it defines a subtly different
> API (wrt to const).
>
> On BSDs there is uuid/uuid.h with an entirely different API, which is
> more akin to the original DCE interface - I'm guessing this is what
> you're encountering (MacOS?)
>
> On Windows the header file is entirele different rpcdce.h I think with a
> very different API also based on the original DCE interface.
>
> You may need to write a very small shim layer to get it to work: As
> there are only a couple of functions used this shouldn't be very hard.
>
> Hope this helps.
>
> Andrew
>
>>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

-- 
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.

Re: Review Request: qpidd refactor

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5833/
---

(Updated Aug. 2, 2012, 8:25 p.m.)


Review request for qpid, Alan Conway and Kenneth Giusti.


Changes
---

Further tweaks for windows build.


Description
---

== Background ==

I've been looking at what would be required to get AMQP 1.0 support in
the qpidd broker (using proton-c). In that context I felt there was a
need to refactor the broker code, particularly that part that would be
shared between different protocol versions. Part of the motivation was
clearer separation of 0-10 specific logic, so that 1.0 logic could be
introduced as an alternative. However part of it was also simply the
recognition of some long-standing problems that we have never stopped
to address.

So, here is a patch representing my ideas on what is needed. This is
a little stale again (patch was generated against r13613342) and
needs (yet) another rebase. However it is getting to the point where I'll be 
asking to commit it soon, so if anyone has feedback, now is the time to give it!

== Key Changes ==

qpid::broker::Message

This is now supposed to be a protocol neutral representation of a
message. It no longer exposes qpid::framing::FrameSet. It can be based
on data received in different encodings (this patch only includes the
existing 0-10 encoding).

The immutable, sharable state is separated from the mutable
queue-specific state. Messages themselves are no longer held through a
shared pointer but are passed by reference or copied if needed. The
immutable state (essentially the data as received) *is* still shared
and referenced internally through an intrusive pointer. There is no
longer a message level lock. A message instance is 'owned' by
someother entity (usually the queue it is on) which controls
concurrent access/modification if necessary.

The persistence context is a separate part of the message
also. Currently that can be shared between two message instances if
desired.

qpid::broker::Messages

Switched from using qpid::broker::QueuedMessage (which relied on
shared pointer to message itself and made sequence number the explicit
- and only - way to refer to a specific message) to using modified
Message class directly and a new qpid::broker::QueueCursor.

The cursor is opaque outside the Messages implementation to which it
relates. It provides a way to refer to a specific message (without
directly using sequence number, though at present that is what is used
'under the covers') and/or to track progress through a sequence of
messages (for consumers or other iterating entities).

I.e. its an iterator to a Message within its containing Messages
instance that is not invalidated by changes to that container.

A Messages instance *owns* the Message instances within it. Other
classes access this through a reference or (raw) pointer, or if needed
copy it (the immutable part can be - and is - safely shared).

The codepath for browse/consume is a lot more unified now. You use a
cursor and call Messages::next() in each case. This also lays the
foundation for selectors.

The simplified Messages interface led to a simplied
MessageDistributor. There is still a little more to do to clarify
these separate roles (or indeed perhaps unify them?) but more on that
later.

qpid::broker::amqp_0_10::MessageTransfer

This represents the familiar 0-10 encoding of a message. This class is
broadly similar to the old Message class, based on a FrameSet. However
it represents the shared and essentially immutable state. The
sendHeader() method now explicitly takes a copy of the original
headers and adds to it or otherwise modifies it if needed (e.g. for
redelivered flag, ttl, annotations etc).

[Ideally I'd like to move more of the 0-10 specific classes out of
qpid::broker and into qpid::broker::amqp_0_10, but that has no
functional relevance so I've left existing classes alone for now.]

qpid::broker::Consumer

The deliver() method now takes a QueueCursor (representing a 'handle'
to this message for use in subsequent operations such as accept,
relese etc) and a *constant reference* to the Message itself
(i.e. consumers can't alter the state of the message on the queue
directly, but only through operations on the queue itself).

qpid::broker::QueueRegistry

The actual queue creation has been pulled out into a base class,
QueueFactory. The actual class of the Queue returned can now be varied
and there are two subclasses in the current patch. The first is a
replacement for the ring policy logic, whereby messages are removed
from the queue in order to keep the queue from growing above a
configured limit. The second is for last value queues and simply pulls
the special case behaviour out of the common code path.

The handling of queue configuration has also been made cleaner and
more uniform, based on the QueueSettings class.

qpid:

[jira] [Commented] (QPID-3677) Asserting does not work correctly from JMS

[Michael Chrostowski (JIRA)]

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

Michael Chrostowski commented on QPID-3677:
---

Gordon, I think you're right and this isn't quite the issue I'm seeing. My 
misunderstanding. 

Though the stack trace matches mine and AMQSession_0_10.java:626 NPE in my case 
involves an empty queueName, was hoping it was the same issue as I do use 
assertions. I removed/added/changed them around and everything seems to be 
working. 

I'm not sure what the cause of my issue was, as it seems to be gone with no 
change on my part. 

> Asserting does not work correctly from JMS
> --
>
> Key: QPID-3677
> URL: https://issues.apache.org/jira/browse/QPID-3677
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.14
>Reporter: Gordon Sim
>  Labels: addressing
>
> When there is an exchange named abc, the following address should result in 
> an error being raised:
>   'abc; {assert: always, node: {type: queue}}'
> There is indeed an error raised, but the message is incorrect:
>   org.apache.qpid.AMQException: The name 'abc' supplied in the address 
> doesn't resolve to an exchange or a queue
> More importantly however, changing the node type to topic should result in 
> the resolution and checking passing without error. This is not the case 
> however. Using:
>   'abc; {assert: always, node: {type: topic}}'
> we get exactly the same error.
> Attempting to assert on the exchange type (assuming abc is of type topic):
>   'abc; {assert: always, node: {type: topic, x-declare:{type:fanout}}}' 
> should result in an error due to mismatched expectations on exchange type. 
> However we get the same incorrect exception as above, i.e:
>   org.apache.qpid.AMQException: The name 'abc' supplied in the address 
> doesn't resolve to an exchange or a queue
> And again, if we change the address so that it should pass:
>  'abc; {assert: always, node: {type: topic, x-declare:{type:topic}}}'
> we then get:
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.qpid.client.AMQSession_0_10.sendConsume(AMQSession_0_10.java:626)
>   at 
> org.apache.qpid.client.AMQSession_0_10.sendConsume(AMQSession_0_10.java:83)
>   at 
> org.apache.qpid.client.AMQSession.consumeFromQueue(AMQSession.java:2592)
>   at 
> org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2928)
>   at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:120)
>   at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2048)
>   at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2006)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:346)
>   at 
> org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:574)
>   at 
> org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>   at 
> org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:2004)
>   at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:979)
>   at org.apache.qpid.example.Drain.(Drain.java:70)
>   at org.apache.qpid.example.Drain.main(Drain.java:103)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-2367) Early Initialization of File Descriptors Conflicts With Daemon Best Practices

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher commented on QPID-2367:
---

This should be fixed now on trunk with r1368685

> Early Initialization of File Descriptors Conflicts With Daemon Best Practices
> -
>
> Key: QPID-2367
> URL: https://issues.apache.org/jira/browse/QPID-2367
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.5
> Environment: Linux (possibly all UNIX), c++, g++
>Reporter: Jason Schlauch
>Assignee: Andrew Stitcher
> Fix For: 0.19
>
>
> At least one file descriptor (in qpid/sys/epoll/EpollPoller.*) in the c++ 
> client is global and declared as static.  In programs linked against the c++ 
> qpid libs g++ generates code for allocation and, more importantly, 
> initialization of these descriptors that occurs before main().  You can 
> confirm this with gdb by breakpointing both the initialization and main() 
> (the initialization break is hit first).
> On the other hand, the canonical recipe for creating a UNIX daemon calls for 
> the closing of all open file descriptors after fork()ing (where the fork() 
> certainly occurs after main()).  While not an absolute requirement, closing 
> all open file descriptors is considered a best practice.  A loop to close all 
> descriptors is also common in boilerplate daemon creation code and has 
> undoubtedly been cut-and-pasted into numerous daemons.
> The net effect is that the typical daemon will close the file descriptor 
> opened before main() in the c++ client library.  In the case of the epoll 
> code this manifests as an inability to connect to the broker.
> A fix for this would be to defer the initialization of the file descriptor 
> (perhaps via the Singleton pattern or a move of the variables into a class 
> member).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-2367) Early Initialization of File Descriptors Conflicts With Daemon Best Practices

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved QPID-2367.
---

   Resolution: Fixed
Fix Version/s: 0.19

> Early Initialization of File Descriptors Conflicts With Daemon Best Practices
> -
>
> Key: QPID-2367
> URL: https://issues.apache.org/jira/browse/QPID-2367
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.5
> Environment: Linux (possibly all UNIX), c++, g++
>Reporter: Jason Schlauch
>Assignee: Andrew Stitcher
> Fix For: 0.19
>
>
> At least one file descriptor (in qpid/sys/epoll/EpollPoller.*) in the c++ 
> client is global and declared as static.  In programs linked against the c++ 
> qpid libs g++ generates code for allocation and, more importantly, 
> initialization of these descriptors that occurs before main().  You can 
> confirm this with gdb by breakpointing both the initialization and main() 
> (the initialization break is hit first).
> On the other hand, the canonical recipe for creating a UNIX daemon calls for 
> the closing of all open file descriptors after fork()ing (where the fork() 
> certainly occurs after main()).  While not an absolute requirement, closing 
> all open file descriptors is considered a best practice.  A loop to close all 
> descriptors is also common in boilerplate daemon creation code and has 
> undoubtedly been cut-and-pasted into numerous daemons.
> The net effect is that the typical daemon will close the file descriptor 
> opened before main() in the c++ client library.  In the case of the epoll 
> code this manifests as an inability to connect to the broker.
> A fix for this would be to defer the initialization of the file descriptor 
> (perhaps via the Singleton pattern or a move of the variables into a class 
> member).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: What libraries/versions for proton?

[Andrew Stitcher]

On Thu, 2012-08-02 at 15:55 -0400, Joseph Ottinger wrote:
> I was building proton-c and the build fails in messenger.c, trying to
> include .
> 
> There's a uuid library for C, but it defines different types than
> proton is expecting. Can anyone tell me which uuid library is
> expected? It's looking for a *system* library for uuid.

You don't say which platform you are trying to build on. I'm guessing
it's not Linux.

The uuid functionality is irritatingly different between platforms. The
current proton code compiles on Linux using libuuid libuuid-devel on
Fedora and I think libuuid-dev on Debian based distros.

On Solaris there is also uuid/uuid.h but it defines a subtly different
API (wrt to const).

On BSDs there is uuid/uuid.h with an entirely different API, which is
more akin to the original DCE interface - I'm guessing this is what
you're encountering (MacOS?)

On Windows the header file is entirele different rpcdce.h I think with a
very different API also based on the original DCE interface.

You may need to write a very small shim layer to get it to work: As
there are only a couple of functions used this shouldn't be very hard.

Hope this helps.

Andrew

> 



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

What libraries/versions for proton?

[Joseph Ottinger]

I was building proton-c and the build fails in messenger.c, trying to
include .

There's a uuid library for C, but it defines different types than
proton is expecting. Can anyone tell me which uuid library is
expected? It's looking for a *system* library for uuid.

-- 
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.

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

Re: Review Request: patches for mingw

[Andrew Stitcher]

> On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote:
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h,
> >  line 40
> > 
> >
> > I think it might be better to keep pn_socket_t out of a header file 
> > that will be widely included by arbitrary client code if it is going to 
> > include a windows system header file (with their name space polluting ways 
> > and general large size). Perhaps pn_socket_t is defined with the driver API?
> 
> Cliff Jansen wrote:
> The latter is the problem.  pn_listen_fd() allows the application to pass 
> in a socket to use.
> 
> I am not sure there is a way to avoid pollution and gain access to the 
> Winsock SOCKET definition.
> 
> Thoughts?

Well pn_listener_fd() is defined in driver.h so polluting the namespace of only 
things that include that would be an improvement - types.h is surely more 
widely used in enduser clients. Perhaps it would be better though to put the 
listener and connector APIs in their own interface to lessen this pollution. 

Another possibility might be to use and intptr type on both platforms and have 
wrappers for creation and destruction that avoid the need for the real type - a 
bit heavy handed though it is close to what we do in qpid.


- Andrew


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6302/#review9728
---


On Aug. 1, 2012, 9:23 p.m., Cliff Jansen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6302/
> ---
> 
> (Updated Aug. 1, 2012, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and 
> Rafael Schloming.
> 
> 
> Description
> ---
> 
> This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 
> 2.0.7.
> 
> A push-button build is still a ways off.  The custom_commands in the cmake 
> script to generate the protocol headers don't work yet on Windows.
> 
> The most intrusive change was the introduction of a pn_socket_t type to hold 
> a socket on both Windows and Posix platforms.  An attempt was made to 
> minimize the use of #ifdefs and split platform code into separate posix and 
> windows directories, as is done for the C++ code.  There is so little needed 
> at the moment, this may be overkill.  The qpid-proton-posix library was 
> ditched and combined with the main qpid-proton library.  Instead, the work is 
> done in CMake to assemble the correct shared and platform specific sources as 
> is done in the C++ tree.
> 
> The driver.c implementation is proof of concept using Winsock select().  
> Future work would most likely replace this with an I/O completion port 
> implementation.
> 
> 
> 1. mkdir ...\trunk\proton-c\build
> 
> 2. set env vars as per trunk\config.sh
> 
> 
>   set PATH=C:\Program Files (x86)\CMake 
> 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build
>   set 
> PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set 
> PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk
> 
> 3. generate the headers:
> 
>   cd trunk\proton-c\build
>   python 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py 
> >encodings.h
>   python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py 
> >protocol.h
> 
> 4. build
> 
>   cmake -G "MinGW Makefiles" -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c
>   mingw32-make
>   python ..\..\tests\proton-test
> 
> 
> This addresses bug QPID-4181.
> https://issues.apache.org/jira/browse/QPID-4181
> 
> 
> Diffs
> -
> 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c
>  1368240 
>   
> http://svn.apache.org/repos/asf/q

Re: Review Request: qpidd refactor

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5833/
---

(Updated Aug. 2, 2012, 7:19 p.m.)


Review request for qpid, Alan Conway and Kenneth Giusti.


Changes
---

Fixes for windows build


Description
---

== Background ==

I've been looking at what would be required to get AMQP 1.0 support in
the qpidd broker (using proton-c). In that context I felt there was a
need to refactor the broker code, particularly that part that would be
shared between different protocol versions. Part of the motivation was
clearer separation of 0-10 specific logic, so that 1.0 logic could be
introduced as an alternative. However part of it was also simply the
recognition of some long-standing problems that we have never stopped
to address.

So, here is a patch representing my ideas on what is needed. This is
a little stale again (patch was generated against r13613342) and
needs (yet) another rebase. However it is getting to the point where I'll be 
asking to commit it soon, so if anyone has feedback, now is the time to give it!

== Key Changes ==

qpid::broker::Message

This is now supposed to be a protocol neutral representation of a
message. It no longer exposes qpid::framing::FrameSet. It can be based
on data received in different encodings (this patch only includes the
existing 0-10 encoding).

The immutable, sharable state is separated from the mutable
queue-specific state. Messages themselves are no longer held through a
shared pointer but are passed by reference or copied if needed. The
immutable state (essentially the data as received) *is* still shared
and referenced internally through an intrusive pointer. There is no
longer a message level lock. A message instance is 'owned' by
someother entity (usually the queue it is on) which controls
concurrent access/modification if necessary.

The persistence context is a separate part of the message
also. Currently that can be shared between two message instances if
desired.

qpid::broker::Messages

Switched from using qpid::broker::QueuedMessage (which relied on
shared pointer to message itself and made sequence number the explicit
- and only - way to refer to a specific message) to using modified
Message class directly and a new qpid::broker::QueueCursor.

The cursor is opaque outside the Messages implementation to which it
relates. It provides a way to refer to a specific message (without
directly using sequence number, though at present that is what is used
'under the covers') and/or to track progress through a sequence of
messages (for consumers or other iterating entities).

I.e. its an iterator to a Message within its containing Messages
instance that is not invalidated by changes to that container.

A Messages instance *owns* the Message instances within it. Other
classes access this through a reference or (raw) pointer, or if needed
copy it (the immutable part can be - and is - safely shared).

The codepath for browse/consume is a lot more unified now. You use a
cursor and call Messages::next() in each case. This also lays the
foundation for selectors.

The simplified Messages interface led to a simplied
MessageDistributor. There is still a little more to do to clarify
these separate roles (or indeed perhaps unify them?) but more on that
later.

qpid::broker::amqp_0_10::MessageTransfer

This represents the familiar 0-10 encoding of a message. This class is
broadly similar to the old Message class, based on a FrameSet. However
it represents the shared and essentially immutable state. The
sendHeader() method now explicitly takes a copy of the original
headers and adds to it or otherwise modifies it if needed (e.g. for
redelivered flag, ttl, annotations etc).

[Ideally I'd like to move more of the 0-10 specific classes out of
qpid::broker and into qpid::broker::amqp_0_10, but that has no
functional relevance so I've left existing classes alone for now.]

qpid::broker::Consumer

The deliver() method now takes a QueueCursor (representing a 'handle'
to this message for use in subsequent operations such as accept,
relese etc) and a *constant reference* to the Message itself
(i.e. consumers can't alter the state of the message on the queue
directly, but only through operations on the queue itself).

qpid::broker::QueueRegistry

The actual queue creation has been pulled out into a base class,
QueueFactory. The actual class of the Queue returned can now be varied
and there are two subclasses in the current patch. The first is a
replacement for the ring policy logic, whereby messages are removed
from the queue in order to keep the queue from growing above a
configured limit. The second is for last value queues and simply pulls
the special case behaviour out of the common code path.

The handling of queue configuration has also been made cleaner and
more uniform, based on the QueueSettings class.

qpid::broker::Q

Re: Review Request: patches for mingw

[Andrew Stitcher]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6302/#review9775
---



http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h


In the most recent API (maybe not in the version you started with) there is 
also pn_connector_fd() that also needs modifying in this way.


- Andrew Stitcher


On Aug. 1, 2012, 9:23 p.m., Cliff Jansen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6302/
> ---
> 
> (Updated Aug. 1, 2012, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and 
> Rafael Schloming.
> 
> 
> Description
> ---
> 
> This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 
> 2.0.7.
> 
> A push-button build is still a ways off.  The custom_commands in the cmake 
> script to generate the protocol headers don't work yet on Windows.
> 
> The most intrusive change was the introduction of a pn_socket_t type to hold 
> a socket on both Windows and Posix platforms.  An attempt was made to 
> minimize the use of #ifdefs and split platform code into separate posix and 
> windows directories, as is done for the C++ code.  There is so little needed 
> at the moment, this may be overkill.  The qpid-proton-posix library was 
> ditched and combined with the main qpid-proton library.  Instead, the work is 
> done in CMake to assemble the correct shared and platform specific sources as 
> is done in the C++ tree.
> 
> The driver.c implementation is proof of concept using Winsock select().  
> Future work would most likely replace this with an I/O completion port 
> implementation.
> 
> 
> 1. mkdir ...\trunk\proton-c\build
> 
> 2. set env vars as per trunk\config.sh
> 
> 
>   set PATH=C:\Program Files (x86)\CMake 
> 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build
>   set 
> PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set 
> PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk
> 
> 3. generate the headers:
> 
>   cd trunk\proton-c\build
>   python 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py 
> >encodings.h
>   python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py 
> >protocol.h
> 
> 4. build
> 
>   cmake -G "MinGW Makefiles" -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c
>   mingw32-make
>   python ..\..\tests\proton-test
> 
> 
> This addresses bug QPID-4181.
> https://issues.apache.org/jira/browse/QPID-4181
> 
> 
> Diffs
> -
> 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/driver.h
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/codec/codec.c 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/dispatcher/dispatcher.c
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/framing/framing.c
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/message/message.c
>  1368240 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/network.h 
> PRE-CREATION 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/posix/time.c
>  PRE-CREATION 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h 
> PRE-CREATION 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/driver.c
>  PRE-CREATION 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/time.c
>  PRE-CREATION 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/uuid.c
>  PRE-CREATION 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/tests/proton_tests/messenger.py
>  1368240 
> 
> Diff

Yet more requests for inclusion in 0.18

[Robbie Gemmell]

Hi Justin,

I would like to request that the following JIRAs/commits be considered for
inclusion in 0.18:

https://issues.apache.org/jira/browse/QPID-4184
http://svn.apache.org/viewvc?view=revision&revision=1368597

This changes the broker log4j config to turn queue threshold notifications
back on, as we inadvertantly managed to turn them off during 0.18
development. No change/risk to the broker itself.


https://issues.apache.org/jira/browse/QPID-4173
http://svn.apache.org/viewvc?view=revision&revision=1368528

This changes the broker log4j config to turn off logging of subscription
state changes, as it is incredibly verbose in various situations and
completely drowns out all the other logging so some people just turn off
everything as a result. No change/risk to the broker itself.


https://issues.apache.org/jira/browse/QPID-4172
http://svn.apache.org/viewvc?view=revision&revision=1368519

This restores a thread name after completing a task, to avoid leaving
threads around with stale names. Very contained and low risk change.


https://issues.apache.org/jira/browse/QPID-4182
http://svn.apache.org/viewvc?view=revision&revision=1368506

This sets a default minimum gap between threshold notifications, to avoid
spamming the log file when it is not configured in the configuration files
(and I notice our shipping config even contains such a non-configured
virtualhost). Very contained and low risk change.

The changes were made either by Alex, Phil, or myself, and have then been
reviewed by at least one of the others.

Robbie

[jira] [Resolved] (QPID-4184) queue alert notifications are not being logged by default

[Alex Rudyy (JIRA)]

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

Alex Rudyy resolved QPID-4184.
--

Resolution: Fixed

Reviewed with no comments

> queue alert notifications are not being logged by default
> -
>
> Key: QPID-4184
> URL: https://issues.apache.org/jira/browse/QPID-4184
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.17
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
> Fix For: 0.19
>
>
> Changes made during the 0.17/0.18 development window have resulted in the 
> logging for queue threshold alerts being disabled by default. These should be 
> enabled by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4184) queue alert notifications are not being logged by default

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned QPID-4184:


Assignee: Robbie Gemmell

> queue alert notifications are not being logged by default
> -
>
> Key: QPID-4184
> URL: https://issues.apache.org/jira/browse/QPID-4184
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.17
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.19
>
>
> Changes made during the 0.17/0.18 development window have resulted in the 
> logging for queue threshold alerts being disabled by default. These should be 
> enabled by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4184) queue alert notifications are not being logged by default

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned QPID-4184:


Assignee: Alex Rudyy  (was: Robbie Gemmell)

Alex, can you review this change please?

> queue alert notifications are not being logged by default
> -
>
> Key: QPID-4184
> URL: https://issues.apache.org/jira/browse/QPID-4184
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.17
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
> Fix For: 0.19
>
>
> Changes made during the 0.17/0.18 development window have resulted in the 
> logging for queue threshold alerts being disabled by default. These should be 
> enabled by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4184) queue alert notifications are not being logged by default

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-4184:
-

Status: Ready To Review  (was: In Progress)

> queue alert notifications are not being logged by default
> -
>
> Key: QPID-4184
> URL: https://issues.apache.org/jira/browse/QPID-4184
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.17
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.19
>
>
> Changes made during the 0.17/0.18 development window have resulted in the 
> logging for queue threshold alerts being disabled by default. These should be 
> enabled by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Review Request: patches for mingw

[Cliff Jansen]

> On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote:
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt, 
> > line 39
> > 
> >
> > Perhaps it makes sense to move src/driver.c into src/sys/posix/driver.c?

I meant to state in the notes that I would do so in a separate patch, depending 
on whether there was an alternate suggestion to managing the platform specific 
code.


> On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote:
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/types.h,
> >  line 40
> > 
> >
> > I think it might be better to keep pn_socket_t out of a header file 
> > that will be widely included by arbitrary client code if it is going to 
> > include a windows system header file (with their name space polluting ways 
> > and general large size). Perhaps pn_socket_t is defined with the driver API?

The latter is the problem.  pn_listen_fd() allows the application to pass in a 
socket to use.

I am not sure there is a way to avoid pollution and gain access to the Winsock 
SOCKET definition.

Thoughts?


> On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote:
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/uuid.h, 
> > line 29
> > 
> >
> > It seems likely to me that you don't need to #include  in 
> > this header file - just including it in the actual implementation file 
> > would stop it contaminating everything with windows symbols.

I can do that.


> On Aug. 2, 2012, 12:04 a.m., Andrew Stitcher wrote:
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.c, line 
> > 27
> > 
> >
> > Note that strings.h is a purely Unix thing not in the C standard 
> > library.
> > 
> > So the there should be a test like #ifdef __unix__ around it, something 
> > like:
> > #ifdef __unix__
> > # include 
> > #elif defined(_WIN32)
> > # define strcasecmp(a,b) _stricmp((a), (b))
> > #else
> > # error
> > #endif
> > 
> > Although it might be simply better to avoid these not very standard 
> > calls and use tolower() and strcmp().
> > 
> > In fact since I can see you've done that work lower down these lines 
> > can probably be removed completely.

Oops.  This is cruft left behind when I switched to the plan B you noted.  Will 
do.


- Cliff


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6302/#review9728
---


On Aug. 1, 2012, 9:23 p.m., Cliff Jansen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6302/
> ---
> 
> (Updated Aug. 1, 2012, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and 
> Rafael Schloming.
> 
> 
> Description
> ---
> 
> This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 
> 2.0.7.
> 
> A push-button build is still a ways off.  The custom_commands in the cmake 
> script to generate the protocol headers don't work yet on Windows.
> 
> The most intrusive change was the introduction of a pn_socket_t type to hold 
> a socket on both Windows and Posix platforms.  An attempt was made to 
> minimize the use of #ifdefs and split platform code into separate posix and 
> windows directories, as is done for the C++ code.  There is so little needed 
> at the moment, this may be overkill.  The qpid-proton-posix library was 
> ditched and combined with the main qpid-proton library.  Instead, the work is 
> done in CMake to assemble the correct shared and platform specific sources as 
> is done in the C++ tree.
> 
> The driver.c implementation is proof of concept using Winsock select().  
> Future work would most likely replace this with an I/O completion port 
> implementation.
> 
> 
> 1. mkdir ...\trunk\proton-c\build
> 
> 2. set env vars as per trunk\config.sh
> 
> 
>   set PATH=C:\Program Files (x86)\CMake 
> 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build
>   set 
> PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set 
> PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk
> 
> 3. generate the headers:
> 
>   cd trunk\proton-c\build
>   python 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encoding

[jira] [Created] (QPID-4184) queue alert notifications are not being logged by default

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPID-4184:


 Summary: queue alert notifications are not being logged by default
 Key: QPID-4184
 URL: https://issues.apache.org/jira/browse/QPID-4184
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: 0.17
Reporter: Robbie Gemmell
 Fix For: 0.19


Changes made during the 0.17/0.18 development window have resulted in the 
logging for queue threshold alerts being disabled by default. These should be 
enabled by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-4100) New HA federation links do not fail over

[Alan Conway (JIRA)]

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

Alan Conway commented on QPID-4100:
---

Proposal to fix the bug:

1. For the security issue: stop using management for HA replication.
HA code will send store-encoded objects to a separate qpid.ha-replication 
exchange.
Use ACL to restrict access to qpid.ha-replication to the replication user.

Benefits:
- solves the security problem
- separates HA from management, we don't have to bend management to suit HA.
- use store encoding, keep HA in sync with store which is a more logical match.

2. For the addressing issue: replicate changes of failover-url. The link on the 
primary will connect and update its own failover-urls. Replicate those URLs to 
the other brokers. 

> New HA federation links do not fail over
> 
>
> Key: QPID-4100
> URL: https://issues.apache.org/jira/browse/QPID-4100
> Project: Qpid
>  Issue Type: New Feature
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> Given two new-HA clusters and a federation link between the primaries of each 
> cluster: 
> - if the source broker is killed, the route _does_ fail over to the new 
> primary
> - if the destination broker is killed the route _is not_ re-created on the 
> new primary
> Federation link and bridge information should be replicated to all cluster 
> members so when a primary dies the backup that takes over can re-create links 
> and bridges.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-4173.
--

Resolution: Fixed

Patch applied.

> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-4172.
--

Resolution: Fixed

Patch applied.

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-4183:
---

Merged from trunk to 0.18

> [Java Broker] AMQP 1.0 implementation broken by management adaptation layer
> ---
>
> Key: QPID-4183
> URL: https://issues.apache.org/jira/browse/QPID-4183
> Project: Qpid
>  Issue Type: Bug
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: 0.18, 0.19
>
>
> The management adapters added to the broker break the AMQP 1.0 implementation 
> as the implementaion of SessionModel and ConnectionModel is now required or 
> else the connection cannot be properly initiated.
> Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-4183:
--

Fix Version/s: 0.18

> [Java Broker] AMQP 1.0 implementation broken by management adaptation layer
> ---
>
> Key: QPID-4183
> URL: https://issues.apache.org/jira/browse/QPID-4183
> Project: Qpid
>  Issue Type: Bug
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: 0.18, 0.19
>
>
> The management adapters added to the broker break the AMQP 1.0 implementation 
> as the implementaion of SessionModel and ConnectionModel is now required or 
> else the connection cannot be properly initiated.
> Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-4182:
--

Patch applied.

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Review Request: patches for mingw

[Kenneth Giusti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6302/#review9755
---

Ship it!


This looks good.  The only serious comment I have applies less to this patch, 
but more generally to the existing structure of the "driver.c" layer - it needs 
to be abstracted a bit more to ease portability across different networking 
api's and unix/win.


http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt


Actually, I think driver.c should be split in two: there's quite a bit of 
platform generic code in this file that should be shared.

Take a look at the "driver_abstraction" branch upstream.  I've split 
driver.c into two files - isolating (some) of the platform code into a separate 
"impl" file.

To support windows, we'd have to cleave off more code than I have in the 
branch, but it's a start.



http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger.c


The sematics are somewhat different here: 0.0.0.0 == all addresses.  Is 
this change ok?



http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c


Problem: calling sprintf may change errno, which means perror could print 
the wrong description.



http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton-dump.c


ditto



http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/sys/windows/driver.c


See my previous comment re: splitting up this file.

I think we should come up with a layered abstraction here, so we can not 
only support different platforms (win vs unix), but also different i/o mechs 
(poll, epoll, windows completions), and the use of different TLS/SSL impls.


- Kenneth Giusti


On Aug. 1, 2012, 9:23 p.m., Cliff Jansen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6302/
> ---
> 
> (Updated Aug. 1, 2012, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and 
> Rafael Schloming.
> 
> 
> Description
> ---
> 
> This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig 
> 2.0.7.
> 
> A push-button build is still a ways off.  The custom_commands in the cmake 
> script to generate the protocol headers don't work yet on Windows.
> 
> The most intrusive change was the introduction of a pn_socket_t type to hold 
> a socket on both Windows and Posix platforms.  An attempt was made to 
> minimize the use of #ifdefs and split platform code into separate posix and 
> windows directories, as is done for the C++ code.  There is so little needed 
> at the moment, this may be overkill.  The qpid-proton-posix library was 
> ditched and combined with the main qpid-proton library.  Instead, the work is 
> done in CMake to assemble the correct shared and platform specific sources as 
> is done in the C++ tree.
> 
> The driver.c implementation is proof of concept using Winsock select().  
> Future work would most likely replace this with an I/O completion port 
> implementation.
> 
> 
> 1. mkdir ...\trunk\proton-c\build
> 
> 2. set env vars as per trunk\config.sh
> 
> 
>   set PATH=C:\Program Files (x86)\CMake 
> 2.8\bin;C:\python25;C:\mingw_ptn\bin;C:\Windows\System32;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build
>   set 
> PYTHONPATH=c:\cj\work\amqp\proton\mingw4\trunk\tests;c:\cj\work\amqp\proton\mingw4\trunk\proton-c;c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set 
> PYTHON_BINDINGS=c:\cj\work\amqp\proton\mingw4\trunk\proton-c\build\bindings\python
>   set PROTON_HOME=C:\cj\work\amqp\proton\mingw4\trunk
> 
> 3. generate the headers:
> 
>   cd trunk\proton-c\build
>   python 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\codec\encodings.h.py 
> >encodings.h
>   python c:\cj\work\amqp\proton\mingw4\trunk\proton-c\src\protocol.h.py 
> >protocol.h
> 
> 4. build
> 
>   cmake -G "MinGW Makefiles" -DSWIG_EXECUTABLE=C:\swigwin-2.0.7\swig.exe 
> c:\cj\work\amqp\proton\mingw4\trunk\proton-c
>   mingw32-make
>   python ..\..\tests\proton-test
> 
> 
> This addresses bug QPID-4181.
> https://issues.apache.org/jira/browse/QPID-4181
> 
> 
> Diffs
> -
> 
>   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 
> 1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/CMakeLists.txt
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/python.i
>  1368240 
>   
> http://svn.apache.org/repos/asf/qpid/pro

[jira] [Commented] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Justin Ross (JIRA)]

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

Justin Ross commented on QPID-4183:
---

http://svn.apache.org/viewvc?view=revision&revision=1368414

Reviewed by Robbie.  Approved for 0.18.

> [Java Broker] AMQP 1.0 implementation broken by management adaptation layer
> ---
>
> Key: QPID-4183
> URL: https://issues.apache.org/jira/browse/QPID-4183
> Project: Qpid
>  Issue Type: Bug
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: 0.19
>
>
> The management adapters added to the broker break the AMQP 1.0 implementation 
> as the implementaion of SessionModel and ConnectionModel is now required or 
> else the connection cannot be properly initiated.
> Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4173:
---

Assignee: Robbie Gemmell  (was: Philip Harvey)

Reviewed and tested by me. Robbie - please can you commit the patch.

> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4173:
-

Status: Ready To Review  (was: In Progress)

> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4173:
-

Attachment: 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch

Attached a patch resolving the issue

> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Comment Edited] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Alex Rudyy (JIRA)]

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

Alex Rudyy edited comment on QPID-4173 at 8/2/12 2:12 PM:
--

Attached a patch resolving the issue.

Phil,
Could you please review it?

  was (Author: alex.rufous):
Attached a patch resolving the issue
  
> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4173-Switch-off-subscription.state-logger-to-re.patch
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Request for inclusion in 0.18

[Rob Godfrey]

Another request for inclusion into 0.18:  QPID-4183

This fixes a problem whereby the AMQP 1.0 support in the Java broker
was inadvertently broken by some of the management work.  The changes
to the broker are isolated to the AMQP 1.0 support layer and have been
reviewed by Robbie.

Cheers,
Rob

On 1 August 2012 00:38, Robbie Gemmell  wrote:
> Hi Justin,
>
> Thanks for approving QPID-4164 (now merged). Could you take a look at
> QPID-4170 as well?
>
> (I realise you might have spotted it was still RtR when I sent the email,
> sorry; I forgot to ask Keith to press the button, he had actually reviewed
> it before I committed it)
>
> Thanks,
> Robbie
>
> On 30 July 2012 15:20, Robbie Gemmell  wrote:
>
>> Hi Justin,
>>
>> I would like to request that the following commits be considered for
>> inclusion in 0.18:
>>
>> https://issues.apache.org/jira/browse/QPID-4164
>> http://svn.apache.org/viewvc?view=revision&revision=1366339
>> http://svn.apache.org/viewvc?view=revision&revision=1365832
>> http://svn.apache.org/viewvc?view=revision&revision=1367095
>>
>> The above commits fix / add tests for an issue whereby moving/copying
>> persistent messages between queues (either manually via the management
>> interface, or automatically using a feature such as maximum-redelivery on
>> queues configured with with DLQs) can result in loss of the payload if the
>> message was originally recovered from the message store. The change is very
>> isolated (to the message stores) and trivial as-is but would look even
>> smaller if we hadn't inverted the meaning of a boolean.
>>
>> https://issues.apache.org/jira/browse/QPID-4170
>> http://svn.apache.org/viewvc?view=revision&revision=1367084
>>
>> The above commit fixes an issue where JMX management threads can enter a
>> infite loop when viewing the content of messages affected by the issue
>> above, consuming CPU resources and creating additional lock contention in
>> the message store. The change is again very isolated (to the Queue MBean)
>> and trivial.
>>
>> The changes were made either by Keith, Phil, or myself, and have then been
>> reviewed by at least one but usually both of the others.
>>
>> Robbie
>>

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

[jira] [Assigned] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters

[Ted Ross (JIRA)]

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

Ted Ross reassigned QPID-4174:
--

Assignee: Ted Ross

> QMF events for (dis)connecting a client to have few more parameters
> ---
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Qpid Managment Framework
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Assignee: Ted Ross
>Priority: Minor
>  Labels: patch
> Attachments: 0001-connect-event-more-QMF-parameters
>
>
> I suggest enhancing values populated in 3 events relevant for client 
> (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect 
> (i.e. better monitoring allowing to easily identify the process that is e.g. 
> failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the 
> disconnect event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4173:
---

Assignee: Philip Harvey

> [Java Broker] disable the subscription state operational logging by default
> ---
>
> Key: QPID-4173
> URL: https://issues.apache.org/jira/browse/QPID-4173
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
> Fix For: 0.19
>
>
> Disable the subscription state operational logging by default. 
> This logging can be *incredibly* verbose if clients have a low prefetch 
> configured, or there is a large backlog of messages on the queue, because the 
> state will constantly flip between active and suspended as the buffer becomes 
> full,not-full,full,not-full...etc.
> We should disable this by default as it tends to drown all the other logging 
> that is often more useful. It will still be possible to turn the logging on 
> at runtime using the logging management mbean (if the operational logging 
> feature is enabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-4172:


Assignee: Robbie Gemmell  (was: Alex Rudyy)

Reviewed with no comments.

Robbie,

Could you please commit the change

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4172:


Status: Ready To Review  (was: In Progress)

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4172:
---

Assignee: Alex Rudyy  (was: Philip Harvey)

please review patch

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4172:
---

Assignee: Philip Harvey

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4172:


Attachment: 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch

attached patch - HouseKeepingTask now reverts thread name.

> [Java Broker] Virtualhost tasks should reset their thread name upon completion
> --
>
> Key: QPID-4172
> URL: https://issues.apache.org/jira/browse/QPID-4172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4172-HouseKeepingTask-now-reverts-thread-name-b.patch
>
>
> Virtualhost tasks should reset their thread name upon completion should reset 
> their thread name upon completion.
> We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
> as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. 
> These rename the thread at the start of their execution, but do not at the 
> end (as explicitly noted in the code, remove the comment) because it will be 
> reset at the next tasks execution. This can confusingly result in multiple 
> threads with the same name if the pool allocates a task to different threads 
> on subsequent executions, so the tasks should restore the original name when 
> they complete to avoid confusion.
> This will result in the threads always having their generic thread pool name 
> except when executing a given task. It might be useful if we could set the 
> base name for these threads in some way to make them easier to identify, but 
> this may not actually be possible while using a ScheduledThreadPoolExecutor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Philip Harvey (JIRA)]

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

Philip Harvey resolved QPID-4182.
-

Resolution: Fixed
  Assignee: Robbie Gemmell  (was: Philip Harvey)

Reviewed and tested - looks good. 

Robbie - please can you commit?

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4182:
-

Attachment: 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4182:
-

Attachment: (was: 
0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch)

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-4183.
--

   Resolution: Fixed
Fix Version/s: 0.19

Changes seem reasonable (obviously there are several bits not implemented in 
the additions, but they weren't implemented previously either so that isn't 
really an issue), and as they are entirely isolated to the AMQP 1.0 code there 
is no risk to the the broker as a whole I would suggest the changes should be 
requested for inclusion in 0.18 as a result.

> [Java Broker] AMQP 1.0 implementation broken by management adaptation layer
> ---
>
> Key: QPID-4183
> URL: https://issues.apache.org/jira/browse/QPID-4183
> Project: Qpid
>  Issue Type: Bug
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: 0.19
>
>
> The management adapters added to the broker break the AMQP 1.0 implementation 
> as the implementaion of SessionModel and ConnectionModel is now required or 
> else the connection cannot be properly initiated.
> Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-3216) Deadlock between "_lock" (in AMQSession#DisptcherThread) and "_messageDeliveryLock" (in AMQSession.java)

[rabii eugen (JIRA)]

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

rabii eugen commented on QPID-3216:
---

So... what is the solution for this problem? We are facing it right now. 
Update to a higher version of qpid-client libraries?

> Deadlock between "_lock" (in AMQSession#DisptcherThread) and 
> "_messageDeliveryLock" (in AMQSession.java)
> 
>
> Key: QPID-3216
> URL: https://issues.apache.org/jira/browse/QPID-3216
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.10
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
>  Labels: deadlock
> Fix For: Future
>
>
> As per the following thread dump you can clearly see the deadlock between 
> "_lock" (in AMQSession#DisptcherThread) and "_messageDeliveryLock" (in 
> AMQSession.java)
> This is another regression and I am working to identify the rev that caused 
> it and possibly understand the circumstances surrounding the change.
> dispatcher thread already obtained "_lock" in dispatchMessage method.
> dispatcher thread waiting to take "_messageDeliveryLock" in the same method.
> main thread has already obtained "_messageDeliveryLock" in AMQSession.close 
> method.
> main thread waiting to take "_lock" in DispatcherThread.rejectPending method.
>   Found one Java-level deadlock:
>   =
>   "Dispatcher-Channel-0":
> waiting to lock monitor 0x002ac1e6f0b8 (object 0x002a9f040448, a 
> java.lang.Object),
> which is held by "main"
>   "main":
> waiting to lock monitor 0x002ac1e6f010 (object 0x002a9f03ba40, a 
> java.lang.Object),
> which is held by "Dispatcher-Channel-0"
>   Java stack information for the threads listed above:
>   ===
>   "Dispatcher-Channel-0":
>  at 
> org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3315)
>  - waiting to lock<0x002a9f040448>  (a java.lang.Object)
>  - locked<0x002a9f03ba40>  (a java.lang.Object)
>  at 
> org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3096)
>  at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3089)
>  at 
> org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:55)
>  at org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3243)
>  at java.lang.Thread.run(Thread.java:619)
>   "main":
>  at 
> org.apache.qpid.client.AMQSession$Dispatcher.rejectPending(AMQSession.java:3122)
>  - waiting to lock<0x002a9f03ba40>  (a java.lang.Object)
>  at 
> org.apache.qpid.client.AMQSession.confirmConsumerCancelled(AMQSession.java:897)
>  at 
> org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(BasicMessageConsumer_0_10.java:189)
>  at 
> org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:573)
>  - locked<0x002a9ef30aa0>  (a java.lang.Object)
>  at org.apache.qpid.client.AMQSession.closeConsumers(AMQSession.java:2464)
>  at 
> org.apache.qpid.client.AMQSession.closeProducersAndConsumers(AMQSession.java:2514)
>  at org.apache.qpid.client.AMQSession.close(AMQSession.java:731)
>  - locked<0x002a9f040448>  (a java.lang.Object)
>  - locked<0x002a9ef30aa0>  (a java.lang.Object)
>  at org.apache.qpid.client.AMQSession.close(AMQSession.java:708)
>  at 
> org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1003)
>  at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:897)
>  - locked<0x002a9ef30aa0>  (a java.lang.Object)
>  - locked<0x002a9ef30ab0>  (a java.lang.Object)
>  at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:886)
>  - locked<0x002a9f040448>  (a java.lang.Object)
>  - locked<0x002a9ef30ab0>  (a java.lang.Object)
>  at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:870)
>  at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:861)
>  at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:856)
>  at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.tearDown(QpidBrokerTestCase.java:1118)
>  at junit.framework.TestCase.runBare(TestCase.java:130)
>  at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
>  at junit.framework.TestResult$1.protect(TestResult.java:106)
>  at junit.framework.TestResult.runProtected(TestResult.java:124)
>  at junit.framework.TestResult.run(TestResult.java:109)
>  at junit.framework.TestCase.run(TestCase.java:118)
>  at org.apache.qpid.test.utils.QpidTestCa

Re: Deadlock

[eugene]

Well this is a bug in the libraries, I've been looking at the code and here
is (probably obvious for you :) ) problem: 

1. Thread 1 acquires the FailoverMutex
2. Thread 2 acquires the MessageDeliveryLock
3. Thread 1 tries to acquire the MessageDeliveryLock
4. Thread 2 tries to acquire the FailoverMutex

Thus the deadlock. 

Alex, I do not think that it has anything to do with closing Consumers from
Listeners, it's just a side effect.

Thank You,
Eugene.



--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/Deadlock-tp7581518p7581564.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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

[jira] [Updated] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-4183:
--

Status: Ready To Review  (was: In Progress)

> [Java Broker] AMQP 1.0 implementation broken by management adaptation layer
> ---
>
> Key: QPID-4183
> URL: https://issues.apache.org/jira/browse/QPID-4183
> Project: Qpid
>  Issue Type: Bug
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> The management adapters added to the broker break the AMQP 1.0 implementation 
> as the implementaion of SessionModel and ConnectionModel is now required or 
> else the connection cannot be properly initiated.
> Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (QPID-4183) [Java Broker] AMQP 1.0 implementation broken by management adaptation layer

[Rob Godfrey (JIRA)]

Rob Godfrey created QPID-4183:
-

 Summary: [Java Broker] AMQP 1.0 implementation broken by 
management adaptation layer
 Key: QPID-4183
 URL: https://issues.apache.org/jira/browse/QPID-4183
 Project: Qpid
  Issue Type: Bug
Reporter: Rob Godfrey
Assignee: Rob Godfrey


The management adapters added to the broker break the AMQP 1.0 implementation 
as the implementaion of SessionModel and ConnectionModel is now required or 
else the connection cannot be properly initiated.

Add a minimal implementation to restore AMQP 1.0 functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec commented on QPID-4174:
-

I changed the JIRA description as per my comment from 31st July, and attached 
patch.

> QMF events for (dis)connecting a client to have few more parameters
> ---
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Qpid Managment Framework
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
> Attachments: 0001-connect-event-more-QMF-parameters
>
>
> I suggest enhancing values populated in 3 events relevant for client 
> (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect 
> (i.e. better monitoring allowing to easily identify the process that is e.g. 
> failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the 
> disconnect event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-4174:


Attachment: 0001-connect-event-more-QMF-parameters

Except for changing management-schema.xml and calls of the relevant methods, it 
was necessary to move some code from end of ConnectionHandler::Handler::startOk 
method to its beginning. That was required to have filled remote process name, 
PID and parentPID before raising the changed events.

> QMF events for (dis)connecting a client to have few more parameters
> ---
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Qpid Managment Framework
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
> Attachments: 0001-connect-event-more-QMF-parameters
>
>
> I suggest enhancing values populated in 3 events relevant for client 
> (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect 
> (i.e. better monitoring allowing to easily identify the process that is e.g. 
> failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the 
> disconnect event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-4174:


Attachment: (was: 0001_QPID-4174_AllowTCPconn-info.patch)

> QMF events for (dis)connecting a client to have few more parameters
> ---
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Qpid Managment Framework
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
>
> I suggest enhancing values populated in 3 events relevant for client 
> (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect 
> (i.e. better monitoring allowing to easily identify the process that is e.g. 
> failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the 
> disconnect event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-4174:


Component/s: (was: Java Client)
 Qpid Managment Framework
Description: 
I suggest enhancing values populated in 3 events relevant for client 
(dis)connection:

clientConnect
clientConnectFail
clientDisconnect

For these events, I suggest adding values:
remoteParentPid
remotePid
remoteProcessName

That is useful for various reasons:
1) To have better information who just disconnected or failed to connect (i.e. 
better monitoring allowing to easily identify the process that is e.g. failing 
to connect repeatedly)
2) To allow client processes (listening for the events) to easily know the 
disconnect event is relevant to itself by comparing its PID with remotePid.

I am attaching a patch for it.

  was:
Java client does not offer a method to print out active TCP connection (like 
string "127.0.0.1:12345->127.0.0.1:5672"). Pure JMS API does not offer so at 
all, checking sources of Java client shows the underlying TCP socket is kept in 
a private member of a class that does not offer a (readonly) access to the 
member.


The enhancement is meaningful for management purposes to detect connectivity. 
If the Java client listens for QMF updates from the qpid broker, it get events 
like "127.0.0.1:12345->127.0.0.1:5672 disconnected". But currently it can not 
match the event to its local connection(s) as it doesn't know them.

I am attaching a simple patch file such that AMQConnection class is extended by 
getSocketString() method.


Summary: QMF events for (dis)connecting a client to have few more 
parameters  (was: Allow getting information about established TCP connection in 
Java client)

> QMF events for (dis)connecting a client to have few more parameters
> ---
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Qpid Managment Framework
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
>
> I suggest enhancing values populated in 3 events relevant for client 
> (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect 
> (i.e. better monitoring allowing to easily identify the process that is e.g. 
> failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the 
> disconnect event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4182:
-

Status: Ready To Review  (was: In Progress)

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-4182:


Assignee: Philip Harvey  (was: Alex Rudyy)

Phil,
Could you please review the patch?

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4182:
-

Attachment: 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch

Attached a patch resolving the issue

> Define a reasonable default for the 'minimumAlertRepeatGap'
> ---
>
> Key: QPID-4182
> URL: https://issues.apache.org/jira/browse/QPID-4182
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.19
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4182-Set-the-default-minimumAlertRepeatGap-valu.patch
>
>
> Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on 
> config in virtualhosts.xml to actually set a default value. Some users don't 
> have this value (e.g old brokers didnt have the config element, and users 
> copy bits of their config during upgrade), which can result in them getting 
> spammed with excessive multiple alerts (often in the same millisecond). This 
> should be defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (QPID-4091) [Java Broker] Incorrect handling of timeout values on DtxSetTimeout

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-4091.
--

Resolution: Fixed
  Assignee: Robbie Gemmell  (was: Rob Godfrey)

Rob made some changes, which I reviewed, and these fixed the users issue.

> [Java Broker] Incorrect handling of timeout values on DtxSetTimeout
> ---
>
> Key: QPID-4091
> URL: https://issues.apache.org/jira/browse/QPID-4091
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.16
>Reporter: Rob Godfrey
>Assignee: Robbie Gemmell
> Fix For: 0.17
>
>
> As pointed out by Robbie 
> (http://qpid.2158936.n2.nabble.com/XA-RBTIMEOUT-tp7578929p7578994.html) the 
> Java Broker is incorrectly interpretting the timeout value in milliseconds 
> rather than seconds

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (QPID-4171) persistent messages from a non-transactional session can be enqueued out of order

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-4171:
-

Affects Version/s: (was: 0.19)
   (was: 0.18)
Fix Version/s: (was: 0.19)
   0.18
 Assignee: Robbie Gemmell  (was: Keith Wall)

Change merged to the 0.18 branch.

> persistent messages from a non-transactional session can be enqueued out of 
> order
> -
>
> Key: QPID-4171
> URL: https://issues.apache.org/jira/browse/QPID-4171
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store
>Affects Versions: 0.16
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Fix For: 0.18
>
> Attachments: 
> 0001-QPID-4171-Fix-enqueue-ordering-for-persistent-messsa.patch, 
> QPID-4171-scribbles.txt
>
>
> A defect in AsyncAutoCommitTransaction means that occasionally messages 
> delivered by a non-transactional JMS are seen to be enqueued out-of-order and 
> therefore delivered to a consumer out of the expected order.  
> It is this problem that underlies QPID-4014, although as I think this problem 
> is wider than ConflationQueues, I am raising this separately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (QPID-4182) Define a reasonable default for the 'minimumAlertRepeatGap'

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-4182:


 Summary: Define a reasonable default for the 
'minimumAlertRepeatGap'
 Key: QPID-4182
 URL: https://issues.apache.org/jira/browse/QPID-4182
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: 0.16, 0.14, 0.12, 0.10, 0.8, 0.6, 0.19
Reporter: Alex Rudyy
Assignee: Alex Rudyy
Priority: Minor
 Fix For: 0.19


Currently the 'minimumAlertRepeatGap' has a default of 0, and relies on config 
in virtualhosts.xml to actually set a default value. Some users don't have this 
value (e.g old brokers didnt have the config element, and users copy bits of 
their config during upgrade), which can result in them getting spammed with 
excessive multiple alerts (often in the same millisecond). This should be 
defaulted to a reasonable value (e.g 30sec) in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (QPID-3677) Asserting does not work correctly from JMS

[Gordon Sim (JIRA)]

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

Gordon Sim commented on QPID-3677:
--

Does your address have an assertion in it? Does it need to? (Are you sure this 
is the right JIRA?)

> Asserting does not work correctly from JMS
> --
>
> Key: QPID-3677
> URL: https://issues.apache.org/jira/browse/QPID-3677
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.14
>Reporter: Gordon Sim
>  Labels: addressing
>
> When there is an exchange named abc, the following address should result in 
> an error being raised:
>   'abc; {assert: always, node: {type: queue}}'
> There is indeed an error raised, but the message is incorrect:
>   org.apache.qpid.AMQException: The name 'abc' supplied in the address 
> doesn't resolve to an exchange or a queue
> More importantly however, changing the node type to topic should result in 
> the resolution and checking passing without error. This is not the case 
> however. Using:
>   'abc; {assert: always, node: {type: topic}}'
> we get exactly the same error.
> Attempting to assert on the exchange type (assuming abc is of type topic):
>   'abc; {assert: always, node: {type: topic, x-declare:{type:fanout}}}' 
> should result in an error due to mismatched expectations on exchange type. 
> However we get the same incorrect exception as above, i.e:
>   org.apache.qpid.AMQException: The name 'abc' supplied in the address 
> doesn't resolve to an exchange or a queue
> And again, if we change the address so that it should pass:
>  'abc; {assert: always, node: {type: topic, x-declare:{type:topic}}}'
> we then get:
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.qpid.client.AMQSession_0_10.sendConsume(AMQSession_0_10.java:626)
>   at 
> org.apache.qpid.client.AMQSession_0_10.sendConsume(AMQSession_0_10.java:83)
>   at 
> org.apache.qpid.client.AMQSession.consumeFromQueue(AMQSession.java:2592)
>   at 
> org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2928)
>   at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:120)
>   at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2048)
>   at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:2006)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:346)
>   at 
> org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:574)
>   at 
> org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>   at 
> org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:2004)
>   at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:979)
>   at org.apache.qpid.example.Drain.(Drain.java:70)
>   at org.apache.qpid.example.Drain.main(Drain.java:103)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Deadlock

[eugene]

Hello Alex,

It is going to be rather difficult to get a sample code that might reproduce
the issue, since we have a pretty big codebase already..

However is that like a known issue that closing consumers from listeners is
going to provoke deadlocks? 
This is rather an undocumented "feature" :)

Thank You,
Eugene.



--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/Deadlock-tp7581518p7581550.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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