[jira] Updated: (QPID-2370) TTR-Qpid-07-NA failed due to channel error 504 during tear down
[ https://issues.apache.org/jira/browse/QPID-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2370: - Attachment: QPID-2370.CheckClosedBeforeFlow.patch Added patch that causes a session.closed/closing check to be performed before attempting to send the ChannelFlow method. This will not remove the race condition however, it will greatly reduce the chances of a ChannelFlow method occuring AFTER a ChannelClose has been sent. > TTR-Qpid-07-NA failed due to channel error 504 during tear down > --- > > Key: QPID-2370 > URL: https://issues.apache.org/jira/browse/QPID-2370 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Attachments: QPID-2370.CheckClosedBeforeFlow.patch > > > During a full 'RunCore.sh' performance test run TTR-Qpid-07-NA hung holding > the test run up. This appeared to be as a result of a Channel Error that was > thrown during. > Thread-4 2010-01-26 03:29:48,722 ERROR [apache.qpid.client.AMQConnection] > error: > org.apache.qpid.AMQConnectionClosedException: Error: channel is closed [error > code 504: channel error] [error code 504: channel error] > This may have occured during test tear down as the following was logged by > the same thread just after the stack trace. > Thread-4 2010-01-26 03:29:48,725 WARN [apache.qpid.ping.PingTestPerf] There > was an exception during per thread tear down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2370) TTR-Qpid-07-NA failed due to channel error 504 during tear down
[ https://issues.apache.org/jira/browse/QPID-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2370: - Attachment: (was: QPID-2370.CheckClosedBeforeFlow.patch) > TTR-Qpid-07-NA failed due to channel error 504 during tear down > --- > > Key: QPID-2370 > URL: https://issues.apache.org/jira/browse/QPID-2370 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Attachments: QPID-2370.CheckClosedBeforeFlow.patch > > > During a full 'RunCore.sh' performance test run TTR-Qpid-07-NA hung holding > the test run up. This appeared to be as a result of a Channel Error that was > thrown during. > Thread-4 2010-01-26 03:29:48,722 ERROR [apache.qpid.client.AMQConnection] > error: > org.apache.qpid.AMQConnectionClosedException: Error: channel is closed [error > code 504: channel error] [error code 504: channel error] > This may have occured during test tear down as the following was logged by > the same thread just after the stack trace. > Thread-4 2010-01-26 03:29:48,725 WARN [apache.qpid.ping.PingTestPerf] There > was an exception during per thread tear down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2370) TTR-Qpid-07-NA failed due to channel error 504 during tear down
[ https://issues.apache.org/jira/browse/QPID-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2370: - Attachment: QPID-2370.CheckClosedBeforeFlow.patch I did mean to grant permission > TTR-Qpid-07-NA failed due to channel error 504 during tear down > --- > > Key: QPID-2370 > URL: https://issues.apache.org/jira/browse/QPID-2370 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Attachments: QPID-2370.CheckClosedBeforeFlow.patch > > > During a full 'RunCore.sh' performance test run TTR-Qpid-07-NA hung holding > the test run up. This appeared to be as a result of a Channel Error that was > thrown during. > Thread-4 2010-01-26 03:29:48,722 ERROR [apache.qpid.client.AMQConnection] > error: > org.apache.qpid.AMQConnectionClosedException: Error: channel is closed [error > code 504: channel error] [error code 504: channel error] > This may have occured during test tear down as the following was logged by > the same thread just after the stack trace. > Thread-4 2010-01-26 03:29:48,725 WARN [apache.qpid.ping.PingTestPerf] There > was an exception during per thread tear down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2370) TTR-Qpid-07-NA failed due to channel error 504 during tear down
[ https://issues.apache.org/jira/browse/QPID-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2370: - Attachment: QPID-2370-Improve-BrokerDebug.patch Additional patch that improves the broker debug statements making diagnosis of issues easier. > TTR-Qpid-07-NA failed due to channel error 504 during tear down > --- > > Key: QPID-2370 > URL: https://issues.apache.org/jira/browse/QPID-2370 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Attachments: QPID-2370-Improve-BrokerDebug.patch, > QPID-2370.CheckClosedBeforeFlow.patch > > > During a full 'RunCore.sh' performance test run TTR-Qpid-07-NA hung holding > the test run up. This appeared to be as a result of a Channel Error that was > thrown during. > Thread-4 2010-01-26 03:29:48,722 ERROR [apache.qpid.client.AMQConnection] > error: > org.apache.qpid.AMQConnectionClosedException: Error: channel is closed [error > code 504: channel error] [error code 504: channel error] > This may have occured during test tear down as the following was logged by > the same thread just after the stack trace. > Thread-4 2010-01-26 03:29:48,725 WARN [apache.qpid.ping.PingTestPerf] There > was an exception during per thread tear down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2371) Missing includes for MSVC 2005 compiler
[ https://issues.apache.org/jira/browse/QPID-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828105#action_12828105 ] Marcel Roelofs commented on QPID-2371: -- Steve, everything compiles out of the box with the patch to the cmakefile below. The extra define specifies that the compiler targets Windows XP and Windows Server 2003; it's necessary to pull some extra declarations into the Windows header files that are needed to compile qpid. Apparently this (or better) is already the default for VC9 but not for VC8. If the default for VC9 is higher than I guess taking the VC9 default value won't hurt either. --- cpp/src/CMakeLists.txt (revision 904026) +++ cpp/src/CMakeLists.txt (working copy) @@ -404,6 +404,7 @@ /D "NOMINMAX" /D "WIN32_LEAN_AND_MEAN" /D "_SCL_SECURE_NO_WARNINGS" + /D _WIN32_WINNT=0x0501 /wd4244 /wd4800 /wd4355 > Missing includes for MSVC 2005 compiler > --- > > Key: QPID-2371 > URL: https://issues.apache.org/jira/browse/QPID-2371 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.6 > Environment: MSVC 2005 >Reporter: Marcel Roelofs >Assignee: Steve Huston >Priority: Minor > Fix For: 0.7 > > Attachments: msvc2005.patch > > > When compiling the 0.6 release candidate using MSVC 2005 I found some missing > header file includes that prevented qpid to compile out of the box. I'll add > a patch later. > Also I had to add "/D _WIN32_WINNT=0x0501" to the compiler flags during cmake > makefile generation to prevent compile errors in various components, but I've > no idea how to add this to the cmake configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2370) TTR-Qpid-07-NA failed due to channel error 504 during tear down
[ https://issues.apache.org/jira/browse/QPID-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2370: - Attachment: QPID-2370.CheckClosedBeforeFlowWithStateCheck.patch Updated the patch to check the state of the suspension to before creating a thread. This will reduce thread creations. > TTR-Qpid-07-NA failed due to channel error 504 during tear down > --- > > Key: QPID-2370 > URL: https://issues.apache.org/jira/browse/QPID-2370 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Attachments: QPID-2370-Improve-BrokerDebug.patch, > QPID-2370.CheckClosedBeforeFlow.patch, > QPID-2370.CheckClosedBeforeFlowWithStateCheck.patch > > > During a full 'RunCore.sh' performance test run TTR-Qpid-07-NA hung holding > the test run up. This appeared to be as a result of a Channel Error that was > thrown during. > Thread-4 2010-01-26 03:29:48,722 ERROR [apache.qpid.client.AMQConnection] > error: > org.apache.qpid.AMQConnectionClosedException: Error: channel is closed [error > code 504: channel error] [error code 504: channel error] > This may have occured during test tear down as the following was logged by > the same thread just after the stack trace. > Thread-4 2010-01-26 03:29:48,725 WARN [apache.qpid.ping.PingTestPerf] There > was an exception during per thread tear down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2364) Management updates in timer create inconsistencies in a cluster.
[ https://issues.apache.org/jira/browse/QPID-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828113#action_12828113 ] Alan Conway commented on QPID-2364: --- Refactoring done in r904656 > Management updates in timer create inconsistencies in a cluster. > > > Key: QPID-2364 > URL: https://issues.apache.org/jira/browse/QPID-2364 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway > Attachments: periodic-timer.patch > > > Management updates are triggered by a timer. They are not predictable for the > cluster and so can cause cluster shut-downs and inconsistent message delivery. > We have a hack in place that suppresses exceptions when the session receives > completions for transfers not yet sent (which is the usual manifestation of > the > unpredictability). I.e. we have in essence disabled consistency checking for > management sessions. This solved immediate problems but would quickly stop > working if sessions/connections could be used for management and other things > (as will be more likely with QMFv2 where using management becomes quite > straightforward). > In a cluster, management updates need to be synchronized by executing them in > the cluster dispatch thread rather than a timer thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2348) [C++] The HeadersExchange does not support federation
[ https://issues.apache.org/jira/browse/QPID-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-2348. Resolution: Fixed > [C++] The HeadersExchange does not support federation > - > > Key: QPID-2348 > URL: https://issues.apache.org/jira/browse/QPID-2348 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.6 > Environment: all environments >Reporter: Sam Joyce >Assignee: Ted Ross >Priority: Minor > Fix For: 0.7 > > Attachments: fed_headers_exchange-2010-01-27.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > (from Ted Ross) > Currently broker federation only deals with binding keys. Both dynamic and > static federation do not support exchanges which use argument-map data in > their > bindings (i.e. XML, Headers, unknown future extension exchange). > Support for static federation with arguments needs to be added. > Support for dynamic federation that propagates bindings with arguments needs > to > be added. > (from Sam Joyce) > This bug actually breaks down into 4 separate tasks: > 1) Allow the exchange to accept dynamic bindings > 2) Allow the exchange to be used by the qpid-route tool to create dynamic > routes > 3) propagate bind and unbind requests to federated peers > 4) support reOrigin requests in the event the things get into a bit of a flap > (flap being a technical term :) ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2380) define and implement reliability options for senders and receivers
define and implement reliability options for senders and receivers -- Key: QPID-2380 URL: https://issues.apache.org/jira/browse/QPID-2380 Project: Qpid Issue Type: Improvement Components: C++ Client, Python Client Affects Versions: 0.6 Reporter: Gordon Sim Assignee: Rafael H. Schloming c++ client currently only recognises 'reliability' option for receivers (unreliable and at-most-once are handled by no-acks and by auto-deleting temp subscription queues on failover) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2251) Provide portable signal mechanism for the C++ QMF agent API
[ https://issues.apache.org/jira/browse/QPID-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828183#action_12828183 ] Pete MacKinnon commented on QPID-2251: -- Should/could we wrap the type returned from getSignalFd()? Private posix impl on the wrapper returns int, private windows impl returns SOCKET. \Pete > Provide portable signal mechanism for the C++ QMF agent API > --- > > Key: QPID-2251 > URL: https://issues.apache.org/jira/browse/QPID-2251 > Project: Qpid > Issue Type: Improvement > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 > RHEL, Fedora >Reporter: Pete MacKinnon >Assignee: Ted Ross > Fix For: 0.7 > > > Need a portable signaling mechanism in the QMF agent API for Windows and > Posix platforms that encapsulates or hides socket and FD implementations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2381) finalise api around synchronising receiver and sender creation
finalise api around synchronising receiver and sender creation -- Key: QPID-2381 URL: https://issues.apache.org/jira/browse/QPID-2381 Project: Qpid Issue Type: Improvement Components: C++ Client, Python Client Affects Versions: 0.6 Reporter: Gordon Sim Assignee: Rafael H. Schloming The sender() and receiver() calls in the python are not synchronous - on return there is no guarantee that any action has yet been take on the broker or even that the address has been confirmed as for a valid node. Further there is then no obvious way (other than trying to send or fetch) to actually wait until any action has succeeded. On the c++ client the createReceiver() and createSender() calls will only return once the necessary server actions have completed successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2382) implement utility for receiving member updates from failover exchange
implement utility for receiving member updates from failover exchange - Key: QPID-2382 URL: https://issues.apache.org/jira/browse/QPID-2382 Project: Qpid Issue Type: Improvement Components: C++ Client, Python Client Reporter: Gordon Sim Assignee: Rafael H. Schloming -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2380) define and implement reliability options for senders and receivers
[ https://issues.apache.org/jira/browse/QPID-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828192#action_12828192 ] Gordon Sim commented on QPID-2380: -- >From doxygen for c++ client at present: reliability - indicates the level of reliability that the receiver expects. Can be one of unreliable, at-most-once, at-least-once or exactly-once (the latter is not yet correctly supported) unreliable and at-most-once are currently treated as the same and for a receiver they will mean that accept-mode=none is used (for 0-10) and in the case of receiving from an exchange an auto-deleted subscription queue is used meaning that messages can be missed during failover or otherwise when not connected. For senders these mean that an outgoing message is no longer considered pending when it has been written to the wire (regardless of whether the broker has yet received it) [Note: in the current c++ client impl this is not possible and a temporary workaround will be put in place] at-least-once uses accept-mode=explicit (0-10) for receivers and a queue that is not deleted when the session is lost for topic receivers; for senders it results in a replay buffer being maintained and messages replayed when a disconnected connection is reconnected (e.g. on failover). > define and implement reliability options for senders and receivers > -- > > Key: QPID-2380 > URL: https://issues.apache.org/jira/browse/QPID-2380 > Project: Qpid > Issue Type: Improvement > Components: C++ Client, Python Client >Affects Versions: 0.6 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming > > c++ client currently only recognises 'reliability' option for receivers > (unreliable and at-most-once are handled by no-acks and by auto-deleting temp > subscription queues on failover) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r904566 - /qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
Rajith,
Can we have some tests to validate the these new SASL connections?
Cheers
Martin
On 29 January 2010 17:30, wrote:
> Author: rajith
> Date: Fri Jan 29 17:30:39 2010
> New Revision: 904566
>
> URL: http://svn.apache.org/viewvc?rev=904566&view=rev
> Log:
> Corrected a mistake I made in rev904375
>
> Modified:
>
> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
>
> Modified:
> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
> URL:
> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java?rev=904566&r1=904565&r2=904566&view=diff
> ==
> ---
> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
> (original)
> +++
> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
> Fri Jan 29 17:30:39 2010
> @@ -72,7 +72,7 @@
> {
> Connection conn = connection();
>
> - if (conn.getConnectionSettings() != null &
> + if (conn.getConnectionSettings() != null &&
> conn.getConnectionSettings().isUseSASLEncryption())
> {
> sender = new SASLSender(sender);
> @@ -87,7 +87,7 @@
>
> public Receiver receiver(Connection conn)
> {
> - if (conn.getConnectionSettings() != null &
> + if (conn.getConnectionSettings() != null &&
> conn.getConnectionSettings().isUseSASLEncryption())
> {
> SASLReceiver receiver = new SASLReceiver(new InputHandler(new
> Assembler(conn)));
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:commits-subscr...@qpid.apache.org
>
>
--
Martin Ritchie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2367) Early Initialization of File Descriptors Conflicts With Daemon Best Practices
[ https://issues.apache.org/jira/browse/QPID-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828278#action_12828278 ] Jason Schlauch commented on QPID-2367: -- Yes, you don't need to handle anything other than stdout, stdin, and stderr. However, for whatever reason, boilerplate daemon code often suggests (and goes on to implement) closing all file descriptors. So perhaps "best practice" wasn't quite accurate, and "common practice" or "it was in the code you inherited" might be better. I handled this by simply changing the daemon code to close only stdout, stdin, and stderr. Finding the error, however, took up a fair chunk of time. Some defensive coding in the QPID client might save others the same trouble. For example, could you simply check if the fd was open before attempting to use it (and reopen it if it's not)? > 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 > > 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. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2368) Exception Thrown at qpid/sys/epoll/EpollPoller.cpp:254 Leaves Orphan File Descriptor
[
https://issues.apache.org/jira/browse/QPID-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828286#action_12828286
]
Jason Schlauch commented on QPID-2368:
--
How about:
try {
QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD, alwaysReadableFd, &epe));
} catch (...) {
close(epollFd);
throw;
}
> Exception Thrown at qpid/sys/epoll/EpollPoller.cpp:254 Leaves Orphan File
> Descriptor
>
>
> Key: QPID-2368
> URL: https://issues.apache.org/jira/browse/QPID-2368
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.5
> Environment: c++ client
>Reporter: Jason Schlauch
>Priority: Minor
>
> While researching JIRA QPID-2367 I noticed a pileup of file descriptors in
> /proc/PID/fd. I traced the creation of these descriptors back to this chunk
> of code in qpid/sys/epoll/EpollPoller.cpp:
> 244 PollerPrivate() :
> 245 epollFd(::epoll_create(DefaultFds)),
> 246 isShutdown(false) {
> 247 QPID_POSIX_CHECK(epollFd);
> 248 ::sigemptyset(&sigMask);
> 249 // Add always readable fd into our set (but not listening to it
> yet)
> 250 ::epoll_event epe;
> 251 epe.events = 0;
> 252 epe.data.u64 = 0;
> 253 QPID_POSIX_CHECK(::epoll_ctl(epollFd, EPOLL_CTL_ADD,
> alwaysReadableFd, &epe));
> 254 }
> The problem is with the second QPID_POSIX_CHECK -- a macro that throws an
> exception. If an exception is thrown then the file descriptor allocated by
> epollFd(::epoll_create(DefaultFds)) is left dangling. A ::close(epollFd)
> would be needed in the catch() block to free it.
> There are a number of functions with a similar design in EpollPoller.cpp that
> might be similarly affected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r904566 - /qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
As mentioned in the original commit message, the SASL encryption is
not fully functional.
I committed the code in the hopes of working with the developers of
the c++ broker to diagnose the issue.
There is no harm due to it being inactive unless explicitly enabled.
As for tests, as soon as the issue is resolved, I will be adding a new
test profile similar to the SSL profile.
Rajith
On Mon, Feb 1, 2010 at 1:47 PM, Martin Ritchie wrote:
> Rajith,
>
> Can we have some tests to validate the these new SASL connections?
>
> Cheers
>
> Martin
>
> On 29 January 2010 17:30, wrote:
>> Author: rajith
>> Date: Fri Jan 29 17:30:39 2010
>> New Revision: 904566
>>
>> URL: http://svn.apache.org/viewvc?rev=904566&view=rev
>> Log:
>> Corrected a mistake I made in rev904375
>>
>> Modified:
>>
>> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
>>
>> Modified:
>> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
>> URL:
>> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java?rev=904566&r1=904565&r2=904566&view=diff
>> ==
>> ---
>> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
>> (original)
>> +++
>> qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/ConnectionBinding.java
>> Fri Jan 29 17:30:39 2010
>> @@ -72,7 +72,7 @@
>> {
>> Connection conn = connection();
>>
>> - if (conn.getConnectionSettings() != null &
>> + if (conn.getConnectionSettings() != null &&
>> conn.getConnectionSettings().isUseSASLEncryption())
>> {
>> sender = new SASLSender(sender);
>> @@ -87,7 +87,7 @@
>>
>> public Receiver receiver(Connection conn)
>> {
>> - if (conn.getConnectionSettings() != null &
>> + if (conn.getConnectionSettings() != null &&
>> conn.getConnectionSettings().isUseSASLEncryption())
>> {
>> SASLReceiver receiver = new SASLReceiver(new InputHandler(new
>> Assembler(conn)));
>>
>>
>>
>> -
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:commits-subscr...@qpid.apache.org
>>
>>
>
>
>
> --
> Martin Ritchie
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2371) Missing includes for MSVC 2005 compiler
[ https://issues.apache.org/jira/browse/QPID-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828360#action_12828360 ] Steve Huston commented on QPID-2371: Thanks for checking into this, Marcel. I'd rather not lock this in for every build. Can do please check where this is needed? If it's pervasive, please try this change to cpp/src/CMakeLists.txt instead: Index: CMakeLists.txt === --- CMakeLists.txt (revision 905160) +++ CMakeLists.txt (working copy) @@ -409,6 +409,9 @@ /wd4800 /wd4355 ) +if (MSVC80) + add_definitions(/D "_WIN32_WINNT=0x0501") +endif (MSVC80) endif (MSVC) set (qpidcommon_platform_SOURCES > Missing includes for MSVC 2005 compiler > --- > > Key: QPID-2371 > URL: https://issues.apache.org/jira/browse/QPID-2371 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.6 > Environment: MSVC 2005 >Reporter: Marcel Roelofs >Assignee: Steve Huston >Priority: Minor > Fix For: 0.7 > > Attachments: msvc2005.patch > > > When compiling the 0.6 release candidate using MSVC 2005 I found some missing > header file includes that prevented qpid to compile out of the box. I'll add > a patch later. > Also I had to add "/D _WIN32_WINNT=0x0501" to the compiler flags during cmake > makefile generation to prevent compile errors in various components, but I've > no idea how to add this to the cmake configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2251) Provide portable signal mechanism for the C++ QMF agent API
[ https://issues.apache.org/jira/browse/QPID-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828363#action_12828363 ] Steve Huston commented on QPID-2251: I think the changes Ted added (if I understand them correctly) make this a moot point... Ted? > Provide portable signal mechanism for the C++ QMF agent API > --- > > Key: QPID-2251 > URL: https://issues.apache.org/jira/browse/QPID-2251 > Project: Qpid > Issue Type: Improvement > Components: Qpid Managment Framework > Environment: Windows XP SP3, VC++ 9.0 > RHEL, Fedora >Reporter: Pete MacKinnon >Assignee: Ted Ross > Fix For: 0.7 > > > Need a portable signaling mechanism in the QMF agent API for Windows and > Posix platforms that encapsulates or hides socket and FD implementations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
