[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033898#comment-13033898
]
Cliff Jansen commented on QPID-3256:
I can reproduce the problem with a program that is not linked against
qpidclientd but loads and unloads it directly. A deadlock occurs
processing the global static destructors.
Thread 1 blocks waiting for thread 2 to exit/die. It also owns the
infamous loader lock (thanks to the use of FreeLibrary())
ntdll!NtWaitForSingleObject+0xa
KERNELBASE!WaitForSingleObjectEx+0x79
qpidcommond!qpid::sys::Thread::join+0x66 [thread.cpp @ 82]
qpidclientd!qpid::client::`anonymous namespace'::IOThread::~IOThread+0x141
qpidclientd!`qpid::client::`anonymous namespace'::theIO'::`2'::`dynamic atexit
destructor for 'io''+0x26
qpidclientd!_CRT_INIT+0x2dc
qpidclientd!__DllMainCRTStartup+0x11f
qpidclientd!_DllMainCRTStartup+0x31
ntdll!LdrpUnloadDll+0x27d
ntdll!LdrUnloadDll+0x4a
KERNELBASE!FreeLibrary+0x1d
foo!main+0x112
Thread 2 is a zombie trying to die, if only it could get the loader lock
ntdll!NtWaitForSingleObject+0xa
ntdll!RtlpWaitOnCriticalSection+0xe8
ntdll!RtlEnterCriticalSection+0xd1
ntdll!LdrShutdownThread+0x72
ntdll!RtlExitUserThread+0x38
MSVCR90D!_endthreadex+0x33
qpidcommond!`anonymous namespace'::runRunnable+0x3b [thread.cpp @ 34]
MSVCR90D!_callthreadstartex+0x25
MSVCR90D!_threadstartex+0xbd
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d
Deadlock: Thread 1 does not wakeup until Thread 2 really dies, hence
neither thread can make progress.
Thread 2 has nothing left to do except the Windows DLL_THREAD_DETACH
handshake in all associated DLLs. It has clearly finished from the
point of view of the Windows implementation of the Qpid Thread class.
One way to fix this would be to use a private synchronization
mechanism that completes before the call to endthreadex(). I will put
a patch together for review along these lines unless someone objects.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic
[jira] [Updated] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen updated QPID-3256:
---
Attachment: qpid-3256.patch
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Attachments: qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
user32.dll!76297d31()
user32.dll!76297dfa()
EXCEL.EXE!2f324572()
EXCEL.EXE!2f324534()
EXCEL.EXE!2f324441()
MSO.DLL!65b78116()
MSO.DLL!65ba1fd0()
EXCEL.EXE!2f30424b()
msvcr90.dll!749936c5()
msvcr90.dll!749938b3()
msvcr90.dll!749938c5()
msvcr90.dll!749ac40c()
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13049564#comment-13049564
]
Cliff Jansen commented on QPID-3256:
I requested that the reporter test the patch in the JIRA and received the
following response:
fromSmirnov Eugene eugen...@yandex.ru
to Cliff Jansen cliffjan...@gmail.com
dateTue, Jun 14, 2011 at 10:41 AM
subject Re: qpid 3256 excel hang
Hi Cliff
I've checked and it works fine.
Thank you!!!
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Steve Huston
Fix For: 0.11
Attachments: qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
[jira] [Updated] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen updated QPID-3256:
---
Attachment: qpid-3256-3.patch
New patch. Now uses Thread local storage (TLS) instead of a std::map to locate
the ThreadPrivate structure. DllMain baggage still there to manage the
FreeLibrary case.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.11
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
user32.dll!76297d31()
user32.dll!76297dfa()
EXCEL.EXE!2f324572()
EXCEL.EXE!2f324534()
EXCEL.EXE!2f324441()
[jira] [Created] (QPID-3338) qpidxarm CMake target is missing in 0-12
qpidxarm CMake target is missing in 0-12 Key: QPID-3338 URL: https://issues.apache.org/jira/browse/QPID-3338 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12 Environment: Windows with Microsoft compilers (as opposed to mingw) Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.12 cpp/src/CMakeLists.txt was altered for mingw builds in QPID-2905 (r1104662). The qpidxarm target builds the XA distributed transaction resource manager for use with the Microsoft distributed trasanction coordinator. It was targeted for Windows builds only, using the CMake variable WIN32. This variable was changed to _MSC_VER for QPID-2905, presumably to indicate that the build target should only apply to builds using the Microsoft compiler, and not mingw. Unfortunately _MSC_VER is not a recognized CMAKE variable and the qpidxarm target is never generated. The CMake documentation indicates the the variable MSVC should be used to indicate The Microsoft compiler compared to mingw. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3338) qpidxarm CMake target is missing in 0-12
[ https://issues.apache.org/jira/browse/QPID-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064014#comment-13064014 ] Cliff Jansen commented on QPID-3338: The patch tests fine on Fedora to generate makefiles via cmake qpidxarm CMake target is missing in 0-12 Key: QPID-3338 URL: https://issues.apache.org/jira/browse/QPID-3338 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12 Environment: Windows with Microsoft compilers (as opposed to mingw) Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.12 Attachments: jira-3338.patch cpp/src/CMakeLists.txt was altered for mingw builds in QPID-2905 (r1104662). The qpidxarm target builds the XA distributed transaction resource manager for use with the Microsoft distributed trasanction coordinator. It was targeted for Windows builds only, using the CMake variable WIN32. This variable was changed to _MSC_VER for QPID-2905, presumably to indicate that the build target should only apply to builds using the Microsoft compiler, and not mingw. Unfortunately _MSC_VER is not a recognized CMAKE variable and the qpidxarm target is never generated. The CMake documentation indicates the the variable MSVC should be used to indicate The Microsoft compiler compared to mingw. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3338) qpidxarm CMake target is missing in 0-12
[ https://issues.apache.org/jira/browse/QPID-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064393#comment-13064393 ] Cliff Jansen commented on QPID-3338: updated trunk: r1145883 updated 0.12 branch: r1145886 qpidxarm CMake target is missing in 0-12 Key: QPID-3338 URL: https://issues.apache.org/jira/browse/QPID-3338 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12 Environment: Windows with Microsoft compilers (as opposed to mingw) Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.12 Attachments: jira-3338.patch cpp/src/CMakeLists.txt was altered for mingw builds in QPID-2905 (r1104662). The qpidxarm target builds the XA distributed transaction resource manager for use with the Microsoft distributed trasanction coordinator. It was targeted for Windows builds only, using the CMake variable WIN32. This variable was changed to _MSC_VER for QPID-2905, presumably to indicate that the build target should only apply to builds using the Microsoft compiler, and not mingw. Unfortunately _MSC_VER is not a recognized CMAKE variable and the qpidxarm target is never generated. The CMake documentation indicates the the variable MSVC should be used to indicate The Microsoft compiler compared to mingw. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067898#comment-13067898
]
Cliff Jansen commented on QPID-3256:
I wanted to see the patch run through Steve's nightly review board automated
build and test.
It started failing precisely at the same time I did the checkin to trunk, not a
good sign. That plus the recent mingw build problem makes me wonder if it is a
good idea to add it to the release at this time. The person who reported the
JIRA has an earlier version of the patch that works for him.
But I can't say for sure if there is a problem. It may be differences between
my setup and Steve's, i.e. Xp versus WS2008, or different versions of boost or
Visual Studio, or 32 vs 64 bit. Or the Riverace build may be failing for some
unrelated reason.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.13
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069054#comment-13069054
]
Cliff Jansen commented on QPID-3256:
Steve, thanks for looking into the nightly scoreboard build.
Justin, I'm fine with this patch included now. I will apply it asap and send
you mail.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.13
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
user32.dll!76297d31()
user32.dll!76297dfa()
EXCEL.EXE!2f324572()
EXCEL.EXE!2f324534()
EXCEL.EXE!2f324441()
[jira] [Resolved] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved QPID-3256.
Resolution: Fixed
Fix Version/s: (was: 0.13)
0.12
Applied to 0.12 branch r1149268
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.12
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
user32.dll!76297d31()
user32.dll!76297dfa()
EXCEL.EXE!2f324572()
EXCEL.EXE!2f324534()
EXCEL.EXE!2f324441()
MSO.DLL!65b78116()
MSO.DLL!65ba1fd0()
EXCEL.EXE!2f30424b()
[jira] [Resolved] (QPID-3338) qpidxarm CMake target is missing in 0-12
[ https://issues.apache.org/jira/browse/QPID-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-3338. Resolution: Fixed qpidxarm CMake target is missing in 0-12 Key: QPID-3338 URL: https://issues.apache.org/jira/browse/QPID-3338 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12 Environment: Windows with Microsoft compilers (as opposed to mingw) Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.12 Attachments: jira-3338.patch cpp/src/CMakeLists.txt was altered for mingw builds in QPID-2905 (r1104662). The qpidxarm target builds the XA distributed transaction resource manager for use with the Microsoft distributed trasanction coordinator. It was targeted for Windows builds only, using the CMake variable WIN32. This variable was changed to _MSC_VER for QPID-2905, presumably to indicate that the build target should only apply to builds using the Microsoft compiler, and not mingw. Unfortunately _MSC_VER is not a recognized CMAKE variable and the qpidxarm target is never generated. The CMake documentation indicates the the variable MSVC should be used to indicate The Microsoft compiler compared to mingw. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-4008) tcpNoDelay connection setting causes fatal exception on Windows
Cliff Jansen created QPID-4008: -- Summary: tcpNoDelay connection setting causes fatal exception on Windows Key: QPID-4008 URL: https://issues.apache.org/jira/browse/QPID-4008 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.16, 0.17 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.17 For example qpid-perftest --tcp-nodelay terminates abnormally when opening its first connection. The Windows implementation of Socket::setTcpNoDelay lacks a check for INVALID_SOCKET and so fails before the connection is open. It should set nodelay=true and return to set the option correctly later from Socket::createSocket. This is the logic in the Linux implementation. -- 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-4096) Change WCF to link static with Boost
[ https://issues.apache.org/jira/browse/QPID-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403727#comment-13403727 ] Cliff Jansen commented on QPID-4096: I have misgivings that you can build something that is simultaneously managed and static, or coax the CLR to work with it. But I could certainly be wrong about that, and I would be happy to take a look and try to help out if you get stuck on something. Even so, a limitation would be distributed transaction support in the absence of also providing dll equivalents. The qpidxarm module is loaded by the MSDTC process via LoadLibrary and the subsequent use of statically linked qpidclient/boost falls squarely into undefined behaviour territory. Change WCF to link static with Boost Key: QPID-4096 URL: https://issues.apache.org/jira/browse/QPID-4096 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.17 Environment: Windows Reporter: Steve Huston Priority: Minor Currently both C++ and WCF/C++ Interop build with linking Boost dynamically. This requires the Boost DLLs to be present at run time. The C++ client build can change to link Boost statically in the cmake configuration step. This removes the need to have the Boost DLLs available at run time, with the possible increase in linked qpid dll size. The WCF/C++ Interop project is not based on Cmake, so it has no such setting. I'd like to change the WCF/C++ Interop to link statically with Boost to remove the need to have Boost available at run time. This change would make packaging easier, as it would remove the need to package Boost DLLs with Qpid or require a specific Boost version/options to be installed on the target system. -- 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-4096) Change WCF to link static with Boost
[ https://issues.apache.org/jira/browse/QPID-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403957#comment-13403957 ] Cliff Jansen commented on QPID-4096: What you are doing sounds fine. The worry is if any of the qpid or boost libraries themselves link against the static versions of the runtime libraries so that two runtimes run simultaneously. Change WCF to link static with Boost Key: QPID-4096 URL: https://issues.apache.org/jira/browse/QPID-4096 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.17 Environment: Windows Reporter: Steve Huston Priority: Minor Currently both C++ and WCF/C++ Interop build with linking Boost dynamically. This requires the Boost DLLs to be present at run time. The C++ client build can change to link Boost statically in the cmake configuration step. This removes the need to have the Boost DLLs available at run time, with the possible increase in linked qpid dll size. The WCF/C++ Interop project is not based on Cmake, so it has no such setting. I'd like to change the WCF/C++ Interop to link statically with Boost to remove the need to have Boost available at run time. This change would make packaging easier, as it would remove the need to package Boost DLLs with Qpid or require a specific Boost version/options to be installed on the target system. -- 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-4181) proton porting work on Windows
Cliff Jansen created QPID-4181: -- Summary: proton porting work on Windows Key: QPID-4181 URL: https://issues.apache.org/jira/browse/QPID-4181 Project: Qpid Issue Type: Improvement Components: Proton Affects Versions: Future Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.19 Basic porting work of proton for C99 compliant compilers on Windows. -- 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-4071) Solaris native compiler port
[ https://issues.apache.org/jira/browse/QPID-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-4071: --- Fix Version/s: Future Solaris native compiler port Key: QPID-4071 URL: https://issues.apache.org/jira/browse/QPID-4071 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: 0.17 Environment: sparc, solstudio12.2, stlport4 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.17, Future Attachments: QPID-4071.patch Builds on the previous gcc work on Solaris. stlport is the selected target library, since the default one does not work with boost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4071) Solaris native compiler port
[ https://issues.apache.org/jira/browse/QPID-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458477#comment-13458477 ] Cliff Jansen commented on QPID-4071: Moved to future completion. Additional CMake fixes required and basic readme. Solaris native compiler port Key: QPID-4071 URL: https://issues.apache.org/jira/browse/QPID-4071 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: 0.17 Environment: sparc, solstudio12.2, stlport4 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: Future Attachments: QPID-4071.patch Builds on the previous gcc work on Solaris. stlport is the selected target library, since the default one does not work with boost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4071) Solaris native compiler port
[ https://issues.apache.org/jira/browse/QPID-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-4071: --- Fix Version/s: (was: 0.17) Solaris native compiler port Key: QPID-4071 URL: https://issues.apache.org/jira/browse/QPID-4071 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: 0.17 Environment: sparc, solstudio12.2, stlport4 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: Future Attachments: QPID-4071.patch Builds on the previous gcc work on Solaris. stlport is the selected target library, since the default one does not work with boost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4345) Windows memory leak
[ https://issues.apache.org/jira/browse/QPID-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-4345: --- Assignee: Cliff Jansen Windows memory leak --- Key: QPID-4345 URL: https://issues.apache.org/jira/browse/QPID-4345 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12, 0.18 Environment: Windows Reporter: Kerry Bonin Assignee: Cliff Jansen Priority: Blocker Fix For: 0.19 Attachments: windows_close_leak_r1390053.patch In our large system performance test environments we see Broker memory growth until the process crashes. This appears to be reproducible simply by opening and closing connections as fast as possible. Marked as 'Blocker' as it was blocking shipment of our Windows based product - the Broker would exhaust memory and crash itself every few days of operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4345) Windows memory leak
[ https://issues.apache.org/jira/browse/QPID-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466517#comment-13466517 ] Cliff Jansen commented on QPID-4345: Nice. Hats off to you gentlemen. I will apply the patch later this week if no objections pop-up. Windows memory leak --- Key: QPID-4345 URL: https://issues.apache.org/jira/browse/QPID-4345 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12, 0.18 Environment: Windows Reporter: Kerry Bonin Assignee: Cliff Jansen Priority: Blocker Fix For: 0.19 Attachments: windows_close_leak_r1390053.patch In our large system performance test environments we see Broker memory growth until the process crashes. This appears to be reproducible simply by opening and closing connections as fast as possible. Marked as 'Blocker' as it was blocking shipment of our Windows based product - the Broker would exhaust memory and crash itself every few days of operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4330) windows clients hang or fault on exit (static destructors)
[ https://issues.apache.org/jira/browse/QPID-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-4330. Resolution: Fixed fixed r1392093. See https://reviews.apache.org/r/7179/ windows clients hang or fault on exit (static destructors) -- Key: QPID-4330 URL: https://issues.apache.org/jira/browse/QPID-4330 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.16, 0.18 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.19 Windows clients occasionally fail to terminate cleanly after exit() or return from main(). I have examined a large number of stack traces, mostly gibberish presumably from rogue memory writes some time in the past. Two refreshingly clear traces showed failure when direct or indirect threading calls were made from inside a static destructor: ~IOThread and ~WinSockSetup. If a DLL (shared object) is winding up due to the library being unloaded (FreeLibrary), the DLL code has an obligation to clean up resources that could leak, and since the process hasn't exited, existing threads live on and threading primitives are trustworthy. In this case the Windows library may (and should) follow the Linux clean up logic in its static destructors. If the DLL is winding up due to exit() (or return from main()), it is undefined how quickly other threads will be forcefully terminated. Locks may be held indefinitely or falsely released (changed in the Vista time frame). In this case, any fancy footwork is dangerous. The best course of action is to let the OS clean up things it would anyway, i.e. do nothing if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4354) windows clients hang or fault on exit, round N+1
Cliff Jansen created QPID-4354: -- Summary: windows clients hang or fault on exit, round N+1 Key: QPID-4354 URL: https://issues.apache.org/jira/browse/QPID-4354 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.18, 0.19 Environment: Windows. Reporter: Cliff Jansen Assignee: Cliff Jansen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4354) windows clients hang or fault on exit, round N+1
[ https://issues.apache.org/jira/browse/QPID-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-4354: --- Description: Windows clients continue to fault/hang on exit intermittently despite the fix in QPID-4330. Additional traces attached. The qpid::log::Logger static destructor could be treated as in QPID-4330, but it is not clear how a similar intervention could be implemented for the _Fac_tidy atexit() routine which lives in Microsoft's own C++ runtime. My unsubstantiated theory is that the IO threads continue servicing the last close operation, after exit() (or return from main()). Those IO threads can be decapitated arbitrarily by Windows, possibly holding locks or leaving data structures inconsistent (i.e. for malloc/free). I would propose first confirming the theory in a private build with a new function that waits until all pending IO completion counts go to zero, and calling that function just before exit() in the test clients. If the faults/hangs do indeed go away, then investigate if a correct fix would involve the use of such a function in Windows, or whether close() or a Connection's destructor should be made synchronous, or plan C. windows clients hang or fault on exit, round N+1 Key: QPID-4354 URL: https://issues.apache.org/jira/browse/QPID-4354 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.18, 0.19 Environment: Windows. Reporter: Cliff Jansen Assignee: Cliff Jansen Attachments: trace2.txt, trace3.txt Windows clients continue to fault/hang on exit intermittently despite the fix in QPID-4330. Additional traces attached. The qpid::log::Logger static destructor could be treated as in QPID-4330, but it is not clear how a similar intervention could be implemented for the _Fac_tidy atexit() routine which lives in Microsoft's own C++ runtime. My unsubstantiated theory is that the IO threads continue servicing the last close operation, after exit() (or return from main()). Those IO threads can be decapitated arbitrarily by Windows, possibly holding locks or leaving data structures inconsistent (i.e. for malloc/free). I would propose first confirming the theory in a private build with a new function that waits until all pending IO completion counts go to zero, and calling that function just before exit() in the test clients. If the faults/hangs do indeed go away, then investigate if a correct fix would involve the use of such a function in Windows, or whether close() or a Connection's destructor should be made synchronous, or plan C. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4354) windows clients hang or fault on exit, round N+1
[ https://issues.apache.org/jira/browse/QPID-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-4354: --- Attachment: trace3.txt trace2.txt from windbg on XP 32 bit windows clients hang or fault on exit, round N+1 Key: QPID-4354 URL: https://issues.apache.org/jira/browse/QPID-4354 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.18, 0.19 Environment: Windows. Reporter: Cliff Jansen Assignee: Cliff Jansen Attachments: trace2.txt, trace3.txt Windows clients continue to fault/hang on exit intermittently despite the fix in QPID-4330. Additional traces attached. The qpid::log::Logger static destructor could be treated as in QPID-4330, but it is not clear how a similar intervention could be implemented for the _Fac_tidy atexit() routine which lives in Microsoft's own C++ runtime. My unsubstantiated theory is that the IO threads continue servicing the last close operation, after exit() (or return from main()). Those IO threads can be decapitated arbitrarily by Windows, possibly holding locks or leaving data structures inconsistent (i.e. for malloc/free). I would propose first confirming the theory in a private build with a new function that waits until all pending IO completion counts go to zero, and calling that function just before exit() in the test clients. If the faults/hangs do indeed go away, then investigate if a correct fix would involve the use of such a function in Windows, or whether close() or a Connection's destructor should be made synchronous, or plan C. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4345) Windows memory leak
[ https://issues.apache.org/jira/browse/QPID-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-4345. Resolution: Fixed fixed r1397926. Windows memory leak --- Key: QPID-4345 URL: https://issues.apache.org/jira/browse/QPID-4345 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12, 0.18 Environment: Windows Reporter: Kerry Bonin Assignee: Cliff Jansen Priority: Blocker Fix For: 0.19 Attachments: windows_close_leak_r1390053.patch In our large system performance test environments we see Broker memory growth until the process crashes. This appears to be reproducible simply by opening and closing connections as fast as possible. Marked as 'Blocker' as it was blocking shipment of our Windows based product - the Broker would exhaust memory and crash itself every few days of operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4400) WCF HelloWorld example throws an XMLException
[
https://issues.apache.org/jira/browse/QPID-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen reassigned QPID-4400:
--
Assignee: Cliff Jansen
WCF HelloWorld example throws an XMLException
-
Key: QPID-4400
URL: https://issues.apache.org/jira/browse/QPID-4400
Project: Qpid
Issue Type: Bug
Components: WCF/C++ Client
Affects Versions: 0.18
Environment: Windows 7 Professional x64
Visual Studio 2010
.Net FrameWork 4.0
Reporter: Maxim Smityukhov
Assignee: Cliff Jansen
Priority: Trivial
There is an exception on byte[] binaryContent = reader.ReadContentAsBase64();
The reason is no writer.WriteEndElement(); in
protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
byte[] binaryContent = Encoding.UTF8.GetBytes(Hello world!);
writer.WriteStartElement(Binary);
writer.WriteBase64(binaryContent, 0, binaryContent.Length);
// Insert here writer.WriteEndElement();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4400) WCF HelloWorld example throws an XMLException
[
https://issues.apache.org/jira/browse/QPID-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved QPID-4400.
Resolution: Fixed
Fix Version/s: 0.19
Fixed r1405981.
WCF HelloWorld example throws an XMLException
-
Key: QPID-4400
URL: https://issues.apache.org/jira/browse/QPID-4400
Project: Qpid
Issue Type: Bug
Components: WCF/C++ Client
Affects Versions: 0.18
Environment: Windows 7 Professional x64
Visual Studio 2010
.Net FrameWork 4.0
Reporter: Maxim Smityukhov
Assignee: Cliff Jansen
Priority: Trivial
Fix For: 0.19
There is an exception on byte[] binaryContent = reader.ReadContentAsBase64();
The reason is no writer.WriteEndElement(); in
protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
byte[] binaryContent = Encoding.UTF8.GetBytes(Hello world!);
writer.WriteStartElement(Binary);
writer.WriteBase64(binaryContent, 0, binaryContent.Length);
// Insert here writer.WriteEndElement();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4181) proton porting work on Windows
[ https://issues.apache.org/jira/browse/QPID-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-4181. Resolution: Fixed Fix Version/s: 0.21 Fixed r1434577, r1434587, and r1434712 See also https://reviews.apache.org/r/6302/ If this issue had not just resolved, it definitely should indeed have been closed and reopened as a proton JIRA. proton porting work on Windows -- Key: QPID-4181 URL: https://issues.apache.org/jira/browse/QPID-4181 Project: Qpid Issue Type: Improvement Components: Proton Affects Versions: Future Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.21 Basic porting work of proton for C99 compliant compilers on Windows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-2889) WCF client crash with corrupted heap if broker is not available
[ https://issues.apache.org/jira/browse/QPID-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-2889. Resolution: Fixed Fix Version/s: 0.8 This appears fixed based on the comments in 0.8. WCF client crash with corrupted heap if broker is not available --- Key: QPID-2889 URL: https://issues.apache.org/jira/browse/QPID-2889 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: qpid 0.6 cpp broker and WCF Binding OS: Windows 7 x86 Reporter: Daniel Sack Assignee: Cliff Jansen Priority: Critical Fix For: 0.8 If and WCF client is trying to send a message and the broker is not available the client will crash with the following error: Unhandled exception at 0x77912913 in w3wp.exe: 0xC374: A heap has been corrupted. In the windows eventlog you will also find then the following entry: Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b21e Exception code: 0xc374 Fault offset: 0x000c2913 Faulting process id: 0x23e4 Faulting application start time: 0x01cb608bfcb4e9f5 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3620) time conversions fail on solaris
[ https://issues.apache.org/jira/browse/QPID-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-3620. Resolution: Fixed fixed. r1242406 time conversions fail on solaris Key: QPID-3620 URL: https://issues.apache.org/jira/browse/QPID-3620 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.15 Environment: Solaris sparc 64 Reporter: Cliff Jansen Assignee: Cliff Jansen Attachments: QPID-3620-0.patch Condition::wait(Mutex, const AbsTime absoluteTime) fails for far future time during cast/truncation from 64 bit int to posix timespec.tv_sec. The time is actually in the past and the wait times out instantly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4792) Windows UUID processing mingles GUID values
Cliff Jansen created QPID-4792: -- Summary: Windows UUID processing mingles GUID values Key: QPID-4792 URL: https://issues.apache.org/jira/browse/QPID-4792 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.20 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.23 RFC 4122 defines a UUID. A GUID is the same as a UUID in string form, but differs in binary layout. Microsoft operates with GUIDs but confusingly labels them as UUIDs in their documentation and include files. i.e. rpcdce.h: typedef GUID UUID; The binary form matters since it is used over the wire. Mapping a GUID to a UUID (or vice versa) without the layout conversion results in structures with mangled RFC version info and different string representations on Windows and non-Windows systems. Proton currently only calls Microsoft APIs to obtain the string representation of the UUID (which will match the GUID), so it is unaffected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-2378) WCF/C++ Client subtree lacks Apache licensing files
WCF/C++ Client subtree lacks Apache licensing files --- Key: QPID-2378 URL: https://issues.apache.org/jira/browse/QPID-2378 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Licence and Notice files are missing. Requirements described at http://www.apache.org/dev/apply-license.html -- 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-2378) WCF/C++ Client subtree lacks Apache licensing files
[ https://issues.apache.org/jira/browse/QPID-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2378: --- Attachment: QPID-2378.patch LICENSE.txt and NOTICE.txt WCF/C++ Client subtree lacks Apache licensing files --- Key: QPID-2378 URL: https://issues.apache.org/jira/browse/QPID-2378 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Attachments: QPID-2378.patch Original Estimate: 1h Remaining Estimate: 1h Licence and Notice files are missing. Requirements described at http://www.apache.org/dev/apply-license.html -- 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-2397) CMake install to 64 bit Windows uses 32 bit install location
CMake install to 64 bit Windows uses 32 bit install location Key: QPID-2397 URL: https://issues.apache.org/jira/browse/QPID-2397 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6, 0.7 Environment: Windows 64 bit Reporter: Cliff Jansen When installing using the CMake generated installer for Windows 64 bit systems, the default location for the runtime binaries is Program Files (86), which suggests to the user that the installed content is 32 bit (to be run under WoW64). -- 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-2410) perftest hang in SSL on Windows with large buffers
perftest hang in SSL on Windows with large buffers -- Key: QPID-2410 URL: https://issues.apache.org/jira/browse/QPID-2410 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.7 Environment: Windows client, Linux broker Reporter: Cliff Jansen The following command: perftest --count 1 --size 102400 -P ssl --port 5671 --broker linuxhost --username testuser --password secret --mechanism PLAIN hangs on a Windows client. Reducing the message body size to 1024 bytes makes the hang go away, as does turning off SSL. -- 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-2415) Update doc for new SSL support in Windows broker and client
Update doc for new SSL support in Windows broker and client --- Key: QPID-2415 URL: https://issues.apache.org/jira/browse/QPID-2415 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 SSL support has been added to Windows. The SSL related documentation should be updated to reflect that. -- 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-2415) Update doc for new SSL support in Windows broker and client
[ https://issues.apache.org/jira/browse/QPID-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2415: --- Attachment: ssldoc.patch Notes specific to Windows Update doc for new SSL support in Windows broker and client --- Key: QPID-2415 URL: https://issues.apache.org/jira/browse/QPID-2415 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: ssldoc.patch Original Estimate: 1h Remaining Estimate: 1h SSL support has been added to Windows. The SSL related documentation should be updated to reflect that. -- 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-2483) Can't build samples from Windows installer
Can't build samples from Windows installer --- Key: QPID-2483 URL: https://issues.apache.org/jira/browse/QPID-2483 Project: Qpid Issue Type: Improvement Components: Packaging Affects Versions: 0.6 Environment: Windows Vista 64 bit Reporter: Cliff Jansen After installing the 64 bit version on a system without a boost environment, I tried building the direct sample. The following include file was wanted boost/preprocessor/logical/bool.hpp but was not in the boost subtree from the installer. It does exist in the regular boost tree. A second problem is the lack of the appropriate library for the link phase, i.e.: boost_XXX.lib for the corresponding boost_XXX.dll -- 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-2500) Transport security for the WCF channel
Transport security for the WCF channel -- Key: QPID-2500 URL: https://issues.apache.org/jira/browse/QPID-2500 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 SSL and Sasl PLAIN capabilities have been recently ported to the C++ client on Windows. The WCF client can now be enhanced to use these features and to provide the expected transport level security classes and binding parameters for specifying encryption and authentication on the transport channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2500) Transport security for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2500: --- Attachment: QPID-2500-1.patch This patch provides the base functionality and security classes that are expected for specifying authentication and encryption on WCF transports. Transport security for the WCF channel -- Key: QPID-2500 URL: https://issues.apache.org/jira/browse/QPID-2500 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2500-1.patch SSL and Sasl PLAIN capabilities have been recently ported to the C++ client on Windows. The WCF client can now be enhanced to use these features and to provide the expected transport level security classes and binding parameters for specifying encryption and authentication on the transport channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2500) Transport security for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2500: --- Attachment: QPID-2500-3.patch Update WcfPerftest to use SSL and SASL plain Transport security for the WCF channel -- Key: QPID-2500 URL: https://issues.apache.org/jira/browse/QPID-2500 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2500-1.patch, QPID-2500-2.patch, QPID-2500-3.patch SSL and Sasl PLAIN capabilities have been recently ported to the C++ client on Windows. The WCF client can now be enhanced to use these features and to provide the expected transport level security classes and binding parameters for specifying encryption and authentication on the transport channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2500) Transport security for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2500: --- Attachment: QPID-2500-2.patch This patch updates the DTC plugin module to be able to parse data source names for SSL and SASL PLAIN info in the context of an XA resource manager. Transport security for the WCF channel -- Key: QPID-2500 URL: https://issues.apache.org/jira/browse/QPID-2500 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2500-1.patch, QPID-2500-2.patch, QPID-2500-3.patch SSL and Sasl PLAIN capabilities have been recently ported to the C++ client on Windows. The WCF client can now be enhanced to use these features and to provide the expected transport level security classes and binding parameters for specifying encryption and authentication on the transport channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2501) WCF Binding Configuration parameters
WCF Binding Configuration parameters Key: QPID-2501 URL: https://issues.apache.org/jira/browse/QPID-2501 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 The existing configuration capabilities of the WCF channel should be fleshed out to handle transport level security. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2500) Transport security for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856608#action_12856608 ] Cliff Jansen commented on QPID-2500: At a minimum the AmqpCredentialType enumeration will grow and there will be new signatures on the AmqpCredential. If other changes are required, for consistency, the AmqpTransportSecurity structure and its support classes should try to look like existing WCF bindings that support these or similar mechanisms. The existing design follows that principle. As an analogy take a look at HttpTransportSecurity and HttpClientCredentialType for an existing Microsoft binding that handles a wide range of authentication and security options. The base WCF ClientCredentials class can already handle most simple certificate and username/password cases and is meant to be extended to handle special cases and arbitrary security tokens. It's flexible, but not necessarily easy to handle arbitrary proxy and firewall situations. Users may prefer to use an AmqpCredential in many cases. The AmqpCredential provides a mechanism to separate broker credentials from WCF service endpoint credentials and also provides the building blocks for more complex bindings in the future (e.g. failover between multiple brokers). Transport security for the WCF channel -- Key: QPID-2500 URL: https://issues.apache.org/jira/browse/QPID-2500 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2500-1.patch, QPID-2500-2.patch, QPID-2500-3.patch SSL and Sasl PLAIN capabilities have been recently ported to the C++ client on Windows. The WCF client can now be enhanced to use these features and to provide the expected transport level security classes and binding parameters for specifying encryption and authentication on the transport channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2505) WCF project needs to encode/decode all AMQP data types
[ https://issues.apache.org/jira/browse/QPID-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12857098#action_12857098 ] Cliff Jansen commented on QPID-2505: Note that there are two levels of translation. The AmqpTypes subdirectory is meant to eventually provide traditional encoding/serialization from AMQP typed objects to and from binary wire representations. This is where the major work will go. The translation in InputLink.cpp and OutputLink.cpp is between .NET managed objects and C++ native space objects. This happens in the context of passing headers, not the message body content. For the simple types looked at so far, the approach has been to call the most direct managed or native getter/setter/constructor of the type. For arbitrarily complex headers, presumably a full encode/decode step will be necessary. It will be a judgement call when to use either mechanism. But header translation is unlikely to be a performance bottleneck, so you should prefer simplicity over performance to start with. WCF project needs to encode/decode all AMQP data types -- Key: QPID-2505 URL: https://issues.apache.org/jira/browse/QPID-2505 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Environment: Windows Server 2008 Reporter: Chuck Rolke Fix For: 0.7 Original Estimate: 96h Remaining Estimate: 96h Currently the WCF Interop project encodes/decodes only string and int data types. The project needs to do all the AMQP data types. * In directory wcf/src/apache/qpid/interop source files InputLink.cpp and OutputLink.cpp have convenient TODO: markers exposing where the encoder/decoder code might go. * The dotnet project seems to have what might be needed in client/transport/codec/*. The effort would be to move the code from dotnet into wcf/interop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2516) New sample to show how to specify WCF bindings in config files
[ https://issues.apache.org/jira/browse/QPID-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2516: --- Attachment: QPID-2516.patch A simple program and associated configuration file demonstrating binding parameters and registering the configuration extensions for the Qpid channel with the WCF subsystem. New sample to show how to specify WCF bindings in config files -- Key: QPID-2516 URL: https://issues.apache.org/jira/browse/QPID-2516 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2516.patch Original Estimate: 2h Remaining Estimate: 2h -- 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-2557) Hello World example
Hello World example --- Key: QPID-2557 URL: https://issues.apache.org/jira/browse/QPID-2557 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 The WCF client needs a Hello World example to match the existing client examples. -- 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-2557) Hello World example
[ https://issues.apache.org/jira/browse/QPID-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2557: --- Attachment: QPID-2557.patch This patch provides a close approximation to the C++ hello_world.cpp version. The sent and received messages are identical as seen by the broker. One downside is that WCF client is not able to auto create the source queue and it must be separately set up using the qpid-config tools. That will hopefully be fixed in the 0.7 timeframe. Hello World example --- Key: QPID-2557 URL: https://issues.apache.org/jira/browse/QPID-2557 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2557.patch Original Estimate: 1h Remaining Estimate: 1h The WCF client needs a Hello World example to match the existing client examples. -- 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-2560) WCF to WCF PubSub sample is mis-named or needs to be re-designed
[ https://issues.apache.org/jira/browse/QPID-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863250#action_12863250 ] Cliff Jansen commented on QPID-2560: The sample is meant to be run by following the recipe in the qpid/wcf/ReadMe.txt file. In particular, the QCreate commands must be run in advance, and one each of the programs Topic_Producer.exe, Topic_Consumer.exe and Another_Topic_Consumer.exe must be run in the correct order. In this case the sample sends messages via the amq.topic exchange and each consumer receives the whole set of messages. The sample could surely be improved on many levels, including by dispensing with Another_Topic_Consumer altogether and have Topic_Consumer make external calls to QCreate (or better, qpid-config) to create a unique named queue for each instance, so that arbitrary numbers of consumers could be run at a time. But since the ability to create temporary queues is one of the next features to be added to the Channel, using that mechanism is probably the more sensible route to follow once it becomes available. WCF to WCF PubSub sample is mis-named or needs to be re-designed Key: QPID-2560 URL: https://issues.apache.org/jira/browse/QPID-2560 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows WCF Reporter: Ted Ross The WCF sample called WCFToWCFPubSub does not use actual AMQP topic routing and therefore is not an accurate illustration of the publication-subscription pattern. The environment in which this was tested was: Two instances of Topic_Consumer and a single instance of Topic_Producer running. The producer sends ten messages and the two consumers receive a subset (partition of the set) of the messages. This is actually using a shared queue and balancing the traffic between the two consumers, not broadcasting the messages equally to the two consumers as it should. Another, more fundamental, problem is that the message transfer is layered on top of a remote procedure call handled by a service associated with the consumer. This is why this code example balances the sent messages. It is only possible for an RPC to be handled by a single server. RPC is not appropriate for pub-sub since the producer doesn't know, when it produces, how many consumers, if any, there are for each produced message. -- 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-2590) Update install notes for transactions
Update install notes for transactions - Key: QPID-2590 URL: https://issues.apache.org/jira/browse/QPID-2590 Project: Qpid Issue Type: Improvement Components: Packaging Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 The install notes for the Qpid installer should include the necessary steps to configure transaction support on the machine. -- 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-2590) Update install notes for transactions
[ https://issues.apache.org/jira/browse/QPID-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2590: --- Attachment: QPID-2590.patch Updated install notes file with configuration information for transactions. Update install notes for transactions - Key: QPID-2590 URL: https://issues.apache.org/jira/browse/QPID-2590 Project: Qpid Issue Type: Improvement Components: Packaging Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2590.patch The install notes for the Qpid installer should include the necessary steps to configure transaction support on the machine. -- 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-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865861#action_12865861
]
Cliff Jansen commented on QPID-2589:
This new C# API has good potential. I worry though about the choice of
System.String as your starting point. Perhaps you meant to add eventually new
constructors and methods to also match the existing C++:
QPID_CLIENT_EXTERN Message(const char*, size_t);
QPID_CLIENT_EXTERN void setContent(const char* chars, size_t count);
in which case I think .NET folks would appreciate two options for each:
Message(byte[] bytes);
Message(byte[] bytes, int index, int count);
SetContent(byte[] bytes)
SetContent(byte[] bytes, int index, int count);
In any event, it makes more sense that the System.String content be accessed or
set via an encoder, as you probably intend to do for maps and other complex
things. Keep in mind that std::string are a reasonable choice for manipulating
binary content in C++. Trying to do the same thing with *immutable* Strings of
16 bit data is likely to cause severe brain strain during your implementation
and .NET users won't thank you for your trouble.
You might also want to tone down the C++-ness of the API, for example by using
.NET naming conventions (i.e. case for methods), and using properties instead
of methods for things like getMilliseconds() or setSubject().
As a C++/CLI tip, be more defensive when passing responsibility for cleanup of
native objects. I added the try block to your code
Sender ^ Session::createSender (System::String ^ address)
{
// allocate a native sender
::qpid::messaging::Sender * senderp = new ::qpid::messaging::Sender;
try {
// create the sender
*senderp =
sessionp-::qpid::messaging::Session::createSender(QpidMarshal::ToNative(address));
// create a managed sender
Sender ^ newSender = gcnew Sender(senderp, this);
senderp = NULL;
}
finally {
if (senderp !=NULL) {
delete senderp
}
}
return newSender;
}
Otherwise, if there is an exception in createSender() there is a memory leak.
If there is an exception in the Sender() constructor, it is worse. There will
be no finalizer call since the constructor didn't complete, so you wonder did
it catch the exception and delete the native resource? The solution is for the
receiver of the native object, Sender in this case, to take responsibility for
cleanup only as the last thing before returning when an exception is no longer
possible. In this particular case it works out that way because there are only
memory assignments to existing memory. You should look at all the other cases
where you do a similar handoff.
Add a .NET binding to QPID Messaging API
Key: QPID-2589
URL: https://issues.apache.org/jira/browse/QPID-2589
Project: Qpid
Issue Type: New Feature
Components: C++ Client
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Assignee: Ted Ross
Fix For: 0.7
Attachments: qpid_bindings.diff
This binding package is a .NET Interop wrapper around the Qpid Messaging
interface. It exposes the Messaging interface through a series of managed
code classes that may be used by any .NET language.
--
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-2595) WCF programming guide documentation
WCF programming guide documentation --- Key: QPID-2595 URL: https://issues.apache.org/jira/browse/QPID-2595 Project: Qpid Issue Type: Improvement Components: Documentation Affects Versions: 0.7 Reporter: Cliff Jansen Fix For: 0.7 WCF/C++ client programming documentation -- 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-2595) WCF programming guide documentation
[ https://issues.apache.org/jira/browse/QPID-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2595: --- Attachment: QPID-2595.patch A chapter on using the WCF channel with code examples WCF programming guide documentation --- Key: QPID-2595 URL: https://issues.apache.org/jira/browse/QPID-2595 Project: Qpid Issue Type: Improvement Components: Documentation Affects Versions: 0.7 Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2595.patch WCF/C++ client programming documentation -- 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-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866530#action_12866530 ] Cliff Jansen commented on QPID-2589: Would it be possible to build the WCF (channel and service interfaces) on top of this API? Well, no. But that is the same answer for the old 0-10 client code and, nevertheless, the WCF channel uses that for 95% of its work and sneaks around it for some additional functionality. In the end, this new API is *much* less rich, which means the WCF channel may have to work much harder behind the scenes to get its work done. But that still may be the right balance. The API should be true to the target developer base first - how many need to be transaction resource managers or perftest stars? The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario). Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. Their absence in this API is not fatal (just run another thread to block on a session.sync(true)), but reduces options for performance optimizations. The current WCF implementation is impressively speedy and it would be sad to handicap it. I would be most happy to see things evolve so that the messaging API becomes a libc-ish entity that can work in an application that simultaneously uses kernel-ish functionality for finer grained capabilities (without pulling the rug out from under libc). I am all for keeping the Advanced in AMQP. Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- 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-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867219#action_12867219 ] Cliff Jansen commented on QPID-2589: A timeout for send() (to match get() and fetch()) would be useful to WCF since the call can block. Does this seem useful in general? Is there an async receive existing or planned like the older MessageListener? I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions. Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- 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-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867218#action_12867218
]
Cliff Jansen commented on QPID-2589:
One problem is implementing WCF's BeginSend for asynchronous writes. There are
three ways of using them, two shown here:
// nothing blocks
IOutputChannel myChannel;
AsyncCallback sendCallback = new AsyncCallback(this.MyCallback);
// ...
for (i=0; imsgcount; i++) {
msg = myMessageFactory.Create(in loop with callback, i);
myChannel.BeginSend(msg, TimeSpan.MaxValue, mycallbackDelegate, msg);
}
// alternate use
msg = myMessageFactory.Create(polling, 0);
IAsyncResult result = myChannel.BeginSend(msg, TimeSpan.MaxValue, null, null);
while (!result.IsComplete) {
// do something else
}
myChannel.EndSend(result); // could raise exception here
msg.Close();
//...
void MyCallback(IAsyncResult result) {
Message msg = (Message) result.AsyncState;
try {
myChannel.EndSend(result);
}
catch (Exception e) {
Console.WriteLine(message send exception {0}, e);
}
msg.Close();
}
I can't see how to implement this functionality in the new messaging API
without launching a thread to monitor a write(msg, true) for every BeginSend.
In the 0-10 API, I have a single thread that monitors an ordered list of Future
objects:
futurep = new Future(sessionImplp-send(mtcmd, *framesetp));
If there is exception or connection drop, the Future preserves information to
know which messages succeeded and which ones failed.
WcfPerftest with a million messages and a million separate thread instances
would not be pretty, even if they come from a thread pool.
Looking through the existing WCF implementation, the only other Futures that
are used are for XaResults from the various dtx commands. It would be nice to
be able to preserve the async nature for these in the new API going forward. I
think any resource manager would want to have this capability.
Add a .NET binding to QPID Messaging API
Key: QPID-2589
URL: https://issues.apache.org/jira/browse/QPID-2589
Project: Qpid
Issue Type: New Feature
Components: C++ Client
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Assignee: Ted Ross
Fix For: 0.7
Attachments: qpid_bindings.diff
This binding package is a .NET Interop wrapper around the Qpid Messaging
interface. It exposes the Messaging interface through a series of managed
code classes that may be used by any .NET language.
--
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-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867237#action_12867237 ] Cliff Jansen commented on QPID-2589: Dictionarystring, object content = new Dictionarystring, object(); [...] Listobject colors = new Listobject(); [...] Do you think Dictionary and List objects are the best choices? The C++ implementation is more stringent. To match it more closely in semantics, I wonder whether you mean to use AmqpType instead of object above, or create a new Class named Variant to match the C++ implementation. I think AmqpType is the more descriptive name, but consistent naming across clients may be the more important goal here. Otherwise I think you definitely want to use Dictionaries and Lists. Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- 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-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868362#action_12868362 ] Cliff Jansen commented on QPID-2589: Thank-you Gordon for turning your mind to this. You would still want a way to wait for changes to the unsettled list. Much better would be an event notification, see below. But otherwise, that plus sender.getUnsettled() x should do the trick. However I don't think the messaging API is any worse in this respect than the old 0-10 API which required either busy-polling or syncing. Well, the WCF channel uses Future.wait() which is better than either of those options. Even that strategy was criticized during WCF design meetings at Microsoft as wasting a thread resource for each session that witnessed async writes (imagining an application that might simultaneously be servicing 100's or thousands of sessions). A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event notification. Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: cpp_binding_dotnet.patch, map_receiver_update.patch, qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- 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-2646) Qpid Messaging address support for WCF Channel
Qpid Messaging address support for WCF Channel -- Key: QPID-2646 URL: https://issues.apache.org/jira/browse/QPID-2646 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Updating the WCF channel to handle the same address strings as the C++ client is desirable for consistency between clients and also simplifies rebasing the WCF channel on the new messaging API in the future. This JIRA can be used to track functionality as it becomes available in the 0.7 timeframe. -- 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-2646) Qpid Messaging address support for WCF Channel
[ https://issues.apache.org/jira/browse/QPID-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2646: --- Attachment: QPID-2646-2.patch This patch provides updates to the transport channel and Interop layer to create temporary queues (bound to an exchange), point and shoot queues (default exchange), and browse mode. Other advanced address options such as node/link properties and assert are not yet implemented. Use of unimplemented addressing features results in an ArgumenException from the WCF Channel for now. Qpid Messaging address support for WCF Channel -- Key: QPID-2646 URL: https://issues.apache.org/jira/browse/QPID-2646 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Fix For: 0.7 Attachments: QPID-2646-1.patch, QPID-2646-2.patch Updating the WCF channel to handle the same address strings as the C++ client is desirable for consistency between clients and also simplifies rebasing the WCF channel on the new messaging API in the future. This JIRA can be used to track functionality as it becomes available in the 0.7 timeframe. -- 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-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879834#action_12879834
]
Cliff Jansen commented on QPID-2589:
If I add the following to the map example:
byte[] myBytes = new byte[3] { 102, 111, 111};
content[myBytes] = byBytes;
I get a NotImplementedException. Is this a known todo item?
Presumably the dotnet map implementation is intended to interoperate with the
Java MapMessage, including distinguishing between getBytes(), getString() [ and
setBytes(), setString()].
Add a .NET binding to QPID Messaging API
Key: QPID-2589
URL: https://issues.apache.org/jira/browse/QPID-2589
Project: Qpid
Issue Type: New Feature
Components: C++ Client
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Assignee: Ted Ross
Fix For: 0.7
Attachments: cpp_binding_dotnet.patch,
cpp_bindings_qpid_dotnet__cleanup.patch,
cpp_bindings_qpid_dotnet_update.patch,
cpp_bindings_qpid_dotnet_vb-helloworld-uuid.patch, map_receiver_update.patch,
qpid_add_x86_platform.patch, qpid_bindings.diff
This binding package is a .NET Interop wrapper around the Qpid Messaging
interface. It exposes the Messaging interface through a series of managed
code classes that may be used by any .NET language.
--
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-2557) Hello World example
[ https://issues.apache.org/jira/browse/QPID-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-2557. Resolution: Fixed Fixed on trunk r1026737. Hello World example --- Key: QPID-2557 URL: https://issues.apache.org/jira/browse/QPID-2557 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.7 Attachments: QPID-2557.patch Original Estimate: 1h Remaining Estimate: 1h The WCF client needs a Hello World example to match the existing client examples. -- 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-2646) Qpid Messaging address support for WCF Channel
[ https://issues.apache.org/jira/browse/QPID-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-2646. Resolution: Fixed Fixed on trunk r1026915. Qpid Messaging address support for WCF Channel -- Key: QPID-2646 URL: https://issues.apache.org/jira/browse/QPID-2646 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.7 Attachments: QPID-2646-1.patch, QPID-2646-2.patch Updating the WCF channel to handle the same address strings as the C++ client is desirable for consistency between clients and also simplifies rebasing the WCF channel on the new messaging API in the future. This JIRA can be used to track functionality as it becomes available in the 0.7 timeframe. -- 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] Assigned: (QPID-2257) Tests for Transactional WCF channel
[ https://issues.apache.org/jira/browse/QPID-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned QPID-2257: -- Assignee: Cliff Jansen Tests for Transactional WCF channel --- Key: QPID-2257 URL: https://issues.apache.org/jira/browse/QPID-2257 Project: Qpid Issue Type: Task Components: WCF/C++ Client Affects Versions: 0.6 Reporter: Devang Gandhi Assignee: Cliff Jansen Fix For: 0.6 New tests are needed for the transactional functionality of the WCF channel. -- 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] Closed: (QPID-2257) Tests for Transactional WCF channel
[ https://issues.apache.org/jira/browse/QPID-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed QPID-2257. -- Resolution: Duplicate Duplicate of QPID-2359, tests already checked in. Tests for Transactional WCF channel --- Key: QPID-2257 URL: https://issues.apache.org/jira/browse/QPID-2257 Project: Qpid Issue Type: Task Components: WCF/C++ Client Affects Versions: 0.6 Reporter: Devang Gandhi Assignee: Cliff Jansen Fix For: 0.6 New tests are needed for the transactional functionality of the WCF channel. -- 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] Assigned: (QPID-2505) WCF project needs to encode/decode all AMQP data types
[ https://issues.apache.org/jira/browse/QPID-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned QPID-2505: -- Assignee: Cliff Jansen WCF project needs to encode/decode all AMQP data types -- Key: QPID-2505 URL: https://issues.apache.org/jira/browse/QPID-2505 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Environment: Windows Server 2008 Reporter: Chuck Rolke Assignee: Cliff Jansen Fix For: 0.7 Original Estimate: 96h Remaining Estimate: 96h Currently the WCF Interop project encodes/decodes only string and int data types. The project needs to do all the AMQP data types. * In directory wcf/src/apache/qpid/interop source files InputLink.cpp and OutputLink.cpp have convenient TODO: markers exposing where the encoder/decoder code might go. * The dotnet project seems to have what might be needed in client/transport/codec/*. The effort would be to move the code from dotnet into wcf/interop. -- 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-2505) WCF project needs to encode/decode all AMQP data types
[ https://issues.apache.org/jira/browse/QPID-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2505: --- Fix Version/s: (was: 0.7) 0.9 Moving this to next release. WCF project needs to encode/decode all AMQP data types -- Key: QPID-2505 URL: https://issues.apache.org/jira/browse/QPID-2505 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Environment: Windows Server 2008 Reporter: Chuck Rolke Assignee: Cliff Jansen Fix For: 0.9 Original Estimate: 96h Remaining Estimate: 96h Currently the WCF Interop project encodes/decodes only string and int data types. The project needs to do all the AMQP data types. * In directory wcf/src/apache/qpid/interop source files InputLink.cpp and OutputLink.cpp have convenient TODO: markers exposing where the encoder/decoder code might go. * The dotnet project seems to have what might be needed in client/transport/codec/*. The effort would be to move the code from dotnet into wcf/interop. -- 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-2560) WCF to WCF PubSub sample is mis-named or needs to be re-designed
[ https://issues.apache.org/jira/browse/QPID-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2560: --- Affects Version/s: (was: 0.7) 0.9 Move to next release. WCF to WCF PubSub sample is mis-named or needs to be re-designed Key: QPID-2560 URL: https://issues.apache.org/jira/browse/QPID-2560 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.9 Environment: Windows WCF Reporter: Ted Ross The WCF sample called WCFToWCFPubSub does not use actual AMQP topic routing and therefore is not an accurate illustration of the publication-subscription pattern. The environment in which this was tested was: Two instances of Topic_Consumer and a single instance of Topic_Producer running. The producer sends ten messages and the two consumers receive a subset (partition of the set) of the messages. This is actually using a shared queue and balancing the traffic between the two consumers, not broadcasting the messages equally to the two consumers as it should. Another, more fundamental, problem is that the message transfer is layered on top of a remote procedure call handled by a service associated with the consumer. This is why this code example balances the sent messages. It is only possible for an RPC to be handled by a single server. RPC is not appropriate for pub-sub since the producer doesn't know, when it produces, how many consumers, if any, there are for each produced message. -- 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] Assigned: (QPID-2889) WCF client crash with corrupted heap if broker is not available
[ https://issues.apache.org/jira/browse/QPID-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned QPID-2889: -- Assignee: Cliff Jansen WCF client crash with corrupted heap if broker is not available --- Key: QPID-2889 URL: https://issues.apache.org/jira/browse/QPID-2889 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: qpid 0.6 cpp broker and WCF Binding OS: Windows 7 x86 Reporter: Daniel Sack Assignee: Cliff Jansen Priority: Critical If and WCF client is trying to send a message and the broker is not available the client will crash with the following error: Unhandled exception at 0x77912913 in w3wp.exe: 0xC374: A heap has been corrupted. In the windows eventlog you will also find then the following entry: Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b21e Exception code: 0xc374 Fault offset: 0x000c2913 Faulting process id: 0x23e4 Faulting application start time: 0x01cb608bfcb4e9f5 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll -- 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-2923) Qpid Messaging .NET Binding fails to translate exceptions from C++ to .NET
[
https://issues.apache.org/jira/browse/QPID-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927494#action_12927494
]
Cliff Jansen commented on QPID-2923:
I think the beauty of using a member initialization list is overshadowed by
the fact that the
original version mishandles exceptions. I intend to replace all instances of
the .NET
binding's constructors with the same pattern.
+1
I am also in favor of uglifying any C++ code that reads nicely but fails to
highlight managed to native transitions.
Qpid Messaging .NET Binding fails to translate exceptions from C++ to .NET
--
Key: QPID-2923
URL: https://issues.apache.org/jira/browse/QPID-2923
Project: Qpid
Issue Type: Bug
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Assignee: Chuck Rolke
Fix For: 0.7
While adding the FailoverUpdate object a problem in the .NET Binding's scheme
of error handling showed up. This issue will document the original problem
and show a proposed coding pattern to make it better.
Two versions of the FailoverUpdates constructor:
*
Original Version
*
FailoverUpdates::FailoverUpdates(Connection ^ connection) :
failoverupdatesp(new
::qpid::messaging::FailoverUpdates(*(connection-NativeConnection)))
{
}
This looks OK to me from a pure C++ standpoint. The problem comes from the
environment in which this code runs. It is called by a managed C# or other
.NET caller and it calls into the unmanaged C++ Qpid Messaging code. Using
this code when the C++ code throws, the exception goes to a handler that does
not understand what to do with it.
A. If the user has no try-catch in the .NET calling code then a popup box
shows:
---
Microsoft Visual C++ Runtime Library
---
Runtime Error!
Program: ...\src\Debug\csharp.map.sender.vshost.exe
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
in an unusual way? What does that mean? This is not good.
*
Improved Version
*
FailoverUpdates::FailoverUpdates(Connection ^ connection)
{
System::Exception ^ newException = nullptr;
try {
failoverupdatesp = new
::qpid::messaging::FailoverUpdates(*(connection-NativeConnection));
}
catch (const ::qpid::types::Exception error) {
String ^ errmsg = gcnew String(error.what());
newException= gcnew QpidException(errmsg);
}
if (newException != nullptr) {
throw newException;
}
}
The idea is to catch the exception from native C++ and rethrow it as a
System::Exception.
B. Now the user sees:
An unhandled exception of type 'Org.Apache.Qpid.Messaging.QpidException'
occurred in org.apache.qpid.messagingd.dll
Additional information: Connection has not yet been opened
(..\..\cpp\src\qpid\client\Connection.cpp:139)
I think the beauty of using a member initialization list is overshadowed by
the fact that the original version mishandles exceptions. I intend to replace
all instances of the .NET binding's constructors with the same pattern.
--
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-2954) Dummy queue naming error for transcation test
Dummy queue naming error for transcation test - Key: QPID-2954 URL: https://issues.apache.org/jira/browse/QPID-2954 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows WCF Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Minor Fix For: 0.9 When measuring distributed transaction performance, a fake transaction to a dummy queue is used to exclude MSDTC initialization. The queue name is improperly built from a UUID. -- 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-2954) Dummy queue naming error for transcation test
[ https://issues.apache.org/jira/browse/QPID-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-2954. Resolution: Fixed Queue name fixed. revision 1037017. Dummy queue naming error for transcation test - Key: QPID-2954 URL: https://issues.apache.org/jira/browse/QPID-2954 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows WCF Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Minor Fix For: 0.9 Original Estimate: 0.02h Remaining Estimate: 0.02h When measuring distributed transaction performance, a fake transaction to a dummy queue is used to exclude MSDTC initialization. The queue name is improperly built from a UUID. -- 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-2560) WCF to WCF PubSub sample is mis-named or needs to be re-designed
[ https://issues.apache.org/jira/browse/QPID-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2560: --- Fix Version/s: Future I'll see if I can get this done in 0.11 along with some doc and other sample improvements. WCF to WCF PubSub sample is mis-named or needs to be re-designed Key: QPID-2560 URL: https://issues.apache.org/jira/browse/QPID-2560 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.9 Environment: Windows WCF Reporter: Ted Ross Assignee: Cliff Jansen Fix For: Future The WCF sample called WCFToWCFPubSub does not use actual AMQP topic routing and therefore is not an accurate illustration of the publication-subscription pattern. The environment in which this was tested was: Two instances of Topic_Consumer and a single instance of Topic_Producer running. The producer sends ten messages and the two consumers receive a subset (partition of the set) of the messages. This is actually using a shared queue and balancing the traffic between the two consumers, not broadcasting the messages equally to the two consumers as it should. Another, more fundamental, problem is that the message transfer is layered on top of a remote procedure call handled by a service associated with the consumer. This is why this code example balances the sent messages. It is only possible for an RPC to be handled by a single server. RPC is not appropriate for pub-sub since the producer doesn't know, when it produces, how many consumers, if any, there are for each produced message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3193) .NET Binding for Messaging classes need a test to check that binding is still in effect
[
https://issues.apache.org/jira/browse/QPID-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017239#comment-13017239
]
Cliff Jansen commented on QPID-3193:
I think you are approaching this the wrong way.
As the owner of the managed/unmanaged interface, it is your responsibility to
catch and trap exceptions that the user of your class can't handle. Changing
the semantics of Dispose() is not what the user would expect.
A C# coder may innocently write:
[...]
(N) mB.Dispose();
The sample that you show works exactly as it should. Replace your Message
class with System.IO.Stream (or any other IDisposable class), and it will also
fail when you try to access a feature that is undefined for the disposed object.
Conversely, if you faked the dispose because you somehow knew mA still wanted
it, you would have robbed mB of it's attempt to optimize the use of the
unmanaged resource.
If you absolutely need to to let the application know if the message is
disposed, see
http://stackoverflow.com/questions/192206/how-does-one-tell-if-an-idisposable-object-reference-is-disposed
but it is rarely needed, otherwise it would be a commonly used pattern. The
user of mA would usually just use a try catch block if he is worried about an
async dispose since:
if (!mA.IsDisposed) {
// another thread calls mB.Dispose() or mA.Dispose()
mA.DoSomething();
}
still leaves a window open.
Another answer is to have the binding check for a null binding
reference on each and every access and then to throw if the underlying
binding is gone. This is not very appealing from a performance
standpoint.
If your class is meant to be thread safe, you have to take a deeper performance
hit and acquire a lock for the duration of test and use. If you don't need
thread safety, to avoid the test except on failure use:
try {
return messagep-foo();
}
catch (const std::exception error) {
if (someDisposedTestHere) {
throw gcnew ObjectDisposedException(Message foo);
else
throw gcnew MyException(gcnew String(error.what()));
}
I believe this should convert the null pointer (unmaged space) exception for
the user into the expected managed space exception.
.NET Binding for Messaging classes need a test to check that binding is still
in effect
---
Key: QPID-3193
URL: https://issues.apache.org/jira/browse/QPID-3193
Project: Qpid
Issue Type: Improvement
Affects Versions: 0.11
Reporter: Chuck Rolke
Assignee: Chuck Rolke
The .NET Binding for Messaging could be made more user-friendly with the
addition of a property that indicates whether or not the underlying binding
is still available. A C# coder may innocently write:
(1) Message mA = new Message(a);
(2) Message mB = mA;
...
(N) mB.Dispose();
After disposing of message mB then message mA is clobbered. 'Message' is a
'ref class' type and messages mA and mB refer to the same object on managed
heap. When message mB is disposed then the bound C++ Messaging object is
deleted [1]. Any reference to the bound message part of mA will result in an
illegal memory reference (to 0) and a process exit. The .NET runtime can't
catch this fault.
The obvious answer is not to do that. If the second line of code was 'Message
mB = new Message(mA)' then mA and mB would have been completely separate and
disposing of either would have no effect on the other.
Another answer is to have the binding check for a null binding reference on
each and every access and then to throw if the underlying binding is gone.
This is not very appealing from a performance standpoint.
As a compromise I would like to add a property isBound to each class. Users
then have a fighting chance to check that the binding is still in effect and
that function calls on the object shouldn't blow up. This property would be
useful in Assert statements or in debugging.
[1] If anyone knows how to have my binding library intercept example code
line (2) and create reference counts, please let me know.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3193) .NET Binding for Messaging classes need a test to check that binding is still in effect
[
https://issues.apache.org/jira/browse/QPID-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017723#comment-13017723
]
Cliff Jansen commented on QPID-3193:
The proposed changes look very good.
As a very minor quibble, it is considered poor form to lock on this or any
public object. I know Microsoft's own documentation is inconsistent about
this, but the .NET police will usually recommend the following:
{quote}
In general, avoid locking on a public type, or instances beyond your code's
control. The common constructs lock (this), lock (typeof (MyType)), and lock
(myLock) violate this guideline:
lock (this) is a problem if the instance can be accessed publicly.
lock (typeof (MyType)) is a problem if MyType is publicly accessible.
lock(myLock) is a problem because any other code in the process using the
same string, will share the same lock.
Best practice is to define a private object to lock on, or a private static
object variable to protect data common to all instances.
{quote}
.NET Binding for Messaging classes need a test to check that binding is still
in effect
---
Key: QPID-3193
URL: https://issues.apache.org/jira/browse/QPID-3193
Project: Qpid
Issue Type: Improvement
Affects Versions: 0.11
Reporter: Chuck Rolke
Assignee: Chuck Rolke
The .NET Binding for Messaging could be made more user-friendly with the
addition of a property that indicates whether or not the underlying binding
is still available. A C# coder may innocently write:
(1) Message mA = new Message(a);
(2) Message mB = mA;
...
(N) mB.Dispose();
After disposing of message mB then message mA is clobbered. 'Message' is a
'ref class' type and messages mA and mB refer to the same object on managed
heap. When message mB is disposed then the bound C++ Messaging object is
deleted [1]. Any reference to the bound message part of mA will result in an
illegal memory reference (to 0) and a process exit. The .NET runtime can't
catch this fault.
The obvious answer is not to do that. If the second line of code was 'Message
mB = new Message(mA)' then mA and mB would have been completely separate and
disposing of either would have no effect on the other.
Another answer is to have the binding check for a null binding reference on
each and every access and then to throw if the underlying binding is gone.
This is not very appealing from a performance standpoint.
As a compromise I would like to add a property isBound to each class. Users
then have a fighting chance to check that the binding is still in effect and
that function calls on the object shouldn't blow up. This property would be
useful in Assert statements or in debugging.
[1] If anyone knows how to have my binding library intercept example code
line (2) and create reference counts, please let me know.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3196) WCF samples should not require external documentation and tools.
WCF samples should not require external documentation and tools. Key: QPID-3196 URL: https://issues.apache.org/jira/browse/QPID-3196 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.8 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: Future Currently the documentation for running the samples is located in a general readme elsewhere in the tree. They rely on a separate tool to create queues and bindings, also located elsewhere in the tree. The samples are therefore difficult to run when accessed using the Windows installer. Rather than updating the installer, the documentation should be shifted and the samples reworked to not require the QCreate tool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1550) C++ broker crashes periodically when handling connection closure
[ https://issues.apache.org/jira/browse/QPID-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-1550: --- Attachment: patch.1550 This bug is caused when AsynchIO::queueForDeletion() is called with (opsInProgress 0). On the subsequent (deferred) AsynchIO::writeComplete() call, a second call is made to AsynchIO::close(). The socket.close() call references memory deleted immediately prior to the the queueForDeletion call (from AsynchIOHandler::closedSocket). The attached patch is one way to fix this. As far as I can tell, the queuedDelete variable is set and tested from within the same thread, so there should be no additional locking issues. C++ broker crashes periodically when handling connection closure Key: QPID-1550 URL: https://issues.apache.org/jira/browse/QPID-1550 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Environment: Windows XP SP2, Visual Studio 2008 SP 1. .NET WCF client (trunk) Reporter: Robert Greig Assignee: Steve Huston Attachments: patch.1550, qpid-broker-log.txt Periodically when running the .NET WCF client against the C++ broker running on windows, the broker crashes. This occurs every 10 runs or thereabouts. Logs and stacks attached. -- 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-2058) SessionImpl::send can't send fresh frames
SessionImpl::send can't send fresh frames --- Key: QPID-2058 URL: https://issues.apache.org/jira/browse/QPID-2058 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen In 0.5, this method could be used to send a message, consisting of a command and separate frame set (consisting of AMQHeaderBody and AMQContentBody frames), or a complete frame set (with the initial command in the frame set discarded): Future SessionImpl::send(const AMQBody command, const FrameSet content) In 0.6, the frame set is re-routed to a MethodContentAdaptor which either hits an exception (for a frame set without initial command), or, for a complete frame set, converts the frames into a single string to reconvert back to individual frames (presumably to adjust for different frame sizes between connections). Perhaps there is some other characteristic of the cluster related frames (other than isCompleted()) that distinguishes them from a fresh set (e.g. hasExchange())? Or possibly a separate command can be used for the cluster case whose intension is to specifically NOT send the frame set provided as the content parameter. If neither of those suggestions lead anywhere, the upcoming patch works for the case of a frame set that lacks a command (method) as its first frame, and works for me, but I don't have a cluster setup to check for unwanted consequences. -- 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-2061) More dll symbol exports for Windows needed in 0.6
More dll symbol exports for Windows needed in 0.6 - Key: QPID-2061 URL: https://issues.apache.org/jira/browse/QPID-2061 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen I propose this Jira to serve as a place to attach patches that solely add dll export syntax sugar for Windows applications during the 0.6 timeframe. -- 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-2061) More dll symbol exports for Windows needed in 0.6
[ https://issues.apache.org/jira/browse/QPID-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2061: --- Attachment: QPID-2061-1.patch symbol exports to allow C# programs to avoid double memory copies and process application headers More dll symbol exports for Windows needed in 0.6 - Key: QPID-2061 URL: https://issues.apache.org/jira/browse/QPID-2061 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: QPID-2061-1.patch I propose this Jira to serve as a place to attach patches that solely add dll export syntax sugar for Windows applications during the 0.6 timeframe. -- 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-2065) New WCF channel using Qpid cpp client libraries
New WCF channel using Qpid cpp client libraries --- Key: QPID-2065 URL: https://issues.apache.org/jira/browse/QPID-2065 Project: Qpid Issue Type: New Feature Affects Versions: 0.6 Environment: Microsoft Windows Reporter: Cliff Jansen Attachments: cj Client software is provided that leverages the existing Qpid C++ libraries to offer a rich programming environment and runtime support for .NET application developers on the Windows platform. The initial focus is on an AMQP Windows Communication Foundation (WCF) channel with transaction support and full programmatic access to AMQP message properties. Follow on work will include broker management capabilities. This first patch provides a basic WCF implementation that supports both WCF-to-WCF and WCF-to-non-WCF applications. Functional tests and sample programs are further provided in related patches. -- 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-2065) New WCF channel using Qpid cpp client libraries
[ https://issues.apache.org/jira/browse/QPID-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2065: --- Attachment: cj main channel source. New WCF channel using Qpid cpp client libraries --- Key: QPID-2065 URL: https://issues.apache.org/jira/browse/QPID-2065 Project: Qpid Issue Type: New Feature Affects Versions: 0.6 Environment: Microsoft Windows Reporter: Cliff Jansen Attachments: cj Client software is provided that leverages the existing Qpid C++ libraries to offer a rich programming environment and runtime support for .NET application developers on the Windows platform. The initial focus is on an AMQP Windows Communication Foundation (WCF) channel with transaction support and full programmatic access to AMQP message properties. Follow on work will include broker management capabilities. This first patch provides a basic WCF implementation that supports both WCF-to-WCF and WCF-to-non-WCF applications. Functional tests and sample programs are further provided in related patches. -- 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-2065) New WCF channel using Qpid cpp client libraries
[ https://issues.apache.org/jira/browse/QPID-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12746388#action_12746388 ] Cliff Jansen commented on QPID-2065: Please see QPID-2066 and QPID-2067 for related software submissions from additional contributors. New WCF channel using Qpid cpp client libraries --- Key: QPID-2065 URL: https://issues.apache.org/jira/browse/QPID-2065 Project: Qpid Issue Type: New Feature Affects Versions: 0.6 Environment: Microsoft Windows Reporter: Cliff Jansen Attachments: cj.zip Client software is provided that leverages the existing Qpid C++ libraries to offer a rich programming environment and runtime support for .NET application developers on the Windows platform. The initial focus is on an AMQP Windows Communication Foundation (WCF) channel with transaction support and full programmatic access to AMQP message properties. Follow on work will include broker management capabilities. This first patch provides a basic WCF implementation that supports both WCF-to-WCF and WCF-to-non-WCF applications. Functional tests and sample programs are further provided in related patches. -- 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-2079) null pointer exception in InputLink
null pointer exception in InputLink --- Key: QPID-2079 URL: https://issues.apache.org/jira/browse/QPID-2079 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen NullRefeneceException is thrown in InputLink::sync() on lock l(waiters) The code is has a race condition where a timeout callback can happen before the handler object is fully initialized. -- 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-2079) null pointer exception in InputLink
[ https://issues.apache.org/jira/browse/QPID-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2079: --- Attachment: QPID-2079.patch Proposed fix. null pointer exception in InputLink --- Key: QPID-2079 URL: https://issues.apache.org/jira/browse/QPID-2079 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: QPID-2079.patch NullRefeneceException is thrown in InputLink::sync() on lock l(waiters) The code is has a race condition where a timeout callback can happen before the handler object is fully initialized. -- 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-2110) Provide local buffering of messages on input links
Provide local buffering of messages on input links -- Key: QPID-2110 URL: https://issues.apache.org/jira/browse/QPID-2110 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen The IInputChannel and InputLink implementations are synchronous, requesting and retrieving one message at a time. Introducing a Prefetch limit corresponding to ongoing message credit to the broker provides substantial read performance benefits. -- 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-2110) Provide local buffering of messages on input links
[ https://issues.apache.org/jira/browse/QPID-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2110: --- Attachment: channel.patch interop.patch interop.patch provides the capability to set and change the PrefetchLimit on the InputLink channel.patch provides the PrefetchLimit property on the AmqpBinding and its use in the transport channel Provide local buffering of messages on input links -- Key: QPID-2110 URL: https://issues.apache.org/jira/browse/QPID-2110 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: channel.patch, interop.patch The IInputChannel and InputLink implementations are synchronous, requesting and retrieving one message at a time. Introducing a Prefetch limit corresponding to ongoing message credit to the broker provides substantial read performance benefits. -- 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-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2128: --- Attachment: qpid2128_1.patch This patch provides distributed transaction support for the C++ based WCF channel on Windows. It basically consists of two new classes in the Interop DLL XaTransaction tracks the sessions that have enlisted in a particular System.Transaction and provides the COM glue to manage the 2PC stages with the Microsoft Distributed Transaction Coordinator. DtxResourceManager is responsible for creating XaTransactions as needed, maintaining the control session with the broker, and initiating and terminating the handshake with MSDTC. and a DtcPlugin module whose purpose is to provide (solely) the recovery functionality of an XA resource manager. This latter DLL runs in the process space of the MSDTC service itself. The nature of this design is that resource manager components do not maintain state between crashes. The MSDTC maintains a log of broker connections and potential in-doubt transactions. It is responsible for initiating recovery as needed. The AMQP broker maintains its own persistent list of transactions that are currently in the prepared state. Those combined logs are sufficient to ensure recovery. 1PC optimization is supported. Promotable transactions cannot be supported with this existing design, but could be with the introduction of an additional log file on the client machine. The AmqpSession class has been enhanced to provide the needed dtx methods in managed space. The remaining changes mainly allow for synchronizing the multiple active sessions. Connections wait on close for outstanding transactions to complete. Dtx join operations have to wait long enough to be sure the broker sees the initial start (on another session or connection) first. A dtx prepare or 1PC must wait for all dtx ends to be processed by the broker (internally referred to as a Phase 0 flush). A set of NUnit tests for all this are coming real soon now. Cliff Transaction support for the WCF channel --- Key: QPID-2128 URL: https://issues.apache.org/jira/browse/QPID-2128 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: qpid2128_1.patch Transaction support is currently lacking from the WCF channel. As an initial implementation, full distributed transaction support from within .NET is proposed using the dtx AMQP classes and creating a plugin to the MSDTC infrastructure to drive recovery. Added performance from promotable transaction enlistment is deferred to a later date. -- 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-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2128: --- Attachment: wcfbld.patch cppbld.patch Here are sample patches for building. The cmake side is what I use, but would need an install component too. The wcf vcproj file should work. I have a self imposed TODO to fix up this aspect of the build, and integrate with cmake if I can. Transaction support for the WCF channel --- Key: QPID-2128 URL: https://issues.apache.org/jira/browse/QPID-2128 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: cppbld.patch, qpid2128_1.patch, wcfbld.patch Transaction support is currently lacking from the WCF channel. As an initial implementation, full distributed transaction support from within .NET is proposed using the dtx AMQP classes and creating a plugin to the MSDTC infrastructure to drive recovery. Added performance from promotable transaction enlistment is deferred to a later date. -- 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-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12782252#action_12782252 ] Cliff Jansen commented on QPID-2128: is there any reason not to just register it even if not used? I have no experience with Microsoft install issues, but I would think it could be done with average registry-related headaches. The registry key in question was specifically introduced to improve security on Windows, so some thought will need to be given to maintaining that as best as possible. Cliff Transaction support for the WCF channel --- Key: QPID-2128 URL: https://issues.apache.org/jira/browse/QPID-2128 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: cppbld.patch, qpid2128_1.patch, wcfbld.patch Transaction support is currently lacking from the WCF channel. As an initial implementation, full distributed transaction support from within .NET is proposed using the dtx AMQP classes and creating a plugin to the MSDTC infrastructure to drive recovery. Added performance from promotable transaction enlistment is deferred to a later date. -- 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-2230) Interoperability test for binary and text messages
[ https://issues.apache.org/jira/browse/QPID-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2230: --- Fix Version/s: 0.6 Affects Version/s: M4 Interoperability test for binary and text messages -- Key: QPID-2230 URL: https://issues.apache.org/jira/browse/QPID-2230 Project: Qpid Issue Type: Test Components: WCF/C++ Client Affects Versions: M4 Environment: Windows WCF client Reporter: Cliff Jansen Fix For: 0.6 A program to test the interoperability of the WCF client and the C++ client would be useful. This would include text and binary data as a first step towards QPID-2226 -- 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-2230) Interoperability test for binary and text messages
[ https://issues.apache.org/jira/browse/QPID-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2230: --- Attachment: QPID-2230.patch This patch includes a WcfPerftest program that provides a subset of the functionality of the original perftest.cpp. If called with no arguments, it runs the WCF client as a subscriber processing messages sent by a C++ perftest instance, then it runs a WCF publisher sending messages to a C++ perftest instance. Binary and text messages are exchanged between the clients. This test is the first interoperability test for the WCF client and would be a nice addition to 0.6. It is standalone and poses a very low risk to impacting existing functionality. Interoperability test for binary and text messages -- Key: QPID-2230 URL: https://issues.apache.org/jira/browse/QPID-2230 Project: Qpid Issue Type: Test Components: WCF/C++ Client Affects Versions: M4 Environment: Windows WCF client Reporter: Cliff Jansen Fix For: 0.6 Attachments: QPID-2230.patch A program to test the interoperability of the WCF client and the C++ client would be useful. This would include text and binary data as a first step towards QPID-2226 -- 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-2247) WCF AmqpChannelListener can hang for 60 seconds on close
WCF AmqpChannelListener can hang for 60 seconds on close Key: QPID-2247 URL: https://issues.apache.org/jira/browse/QPID-2247 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Critical Fix For: 0.6 When closing a WCF service the ChannelListener can hang for 60 seconds, until it times out and aborts. This is known issue #3 in the Readme file. It would be nice to erradicate this for 0.6 -- 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-2260) Build of Release configuration fails
Build of Release configuration fails Key: QPID-2260 URL: https://issues.apache.org/jira/browse/QPID-2260 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Locations for the Release intermediaries are not properly resolved. This is known issue #1 in the ReadMe.txt file and prevents non-debug versions of the code from building without user intervention. This should be easy to fix. -- 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-2267) release artifact for WCF channel
release artifact for WCF channel Key: QPID-2267 URL: https://issues.apache.org/jira/browse/QPID-2267 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Release artifacts build environment Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 The steps to create a release artifact for the WCF channel need to be made explicit. -- 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-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2267: --- Attachment: rel.patch Proposed steps to create the WCF release artifact. provided against the qpid/bin/release.sh script release artifact for WCF channel Key: QPID-2267 URL: https://issues.apache.org/jira/browse/QPID-2267 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Release artifacts build environment Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Attachments: rel.patch Original Estimate: 0.5h Remaining Estimate: 0.5h The steps to create a release artifact for the WCF channel need to be made explicit. -- 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-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790919#action_12790919 ] Cliff Jansen commented on QPID-2128: Thank you very much for the detailed review. Some comments/questions Dtcplugin.cpp 188: should host be checked for empty string? I don't think so. It is only used internally and it would take contorted programming to pass the reference parameter as a null value. 172: i len should be i len-1 since the next line is referencing dsn[i+1] That's a bug, will fix. 324: the qpid SQL storage provider does not log indoubt transactions, so the recover will always get an empty list. If the qpid broker crashes after prepare, the transaction is rolled back by SQL. This may cause data inconsistency because other RMs may commit that transaction already. Need to work with Stephen to figure out if this is an issue in the storage provider implementation. Wow. Triple points for finding that merely from the Windows provider code. Will fix asap, thanks. 454: if the new operator throws due to low memory condition and the exception is handled in some other place, there could be deadlock because the critical section is not released. Bug, will fix. 454 - 464: if you call open first and add the new resource manager to the map when it succeeds, there is no need to erase. Using an auto pointer here can make it easy to release the object on failures. Good point, will rework. 461: what exception can be thrown by delete? The destructor of ResourceManager is empty. The destructors of Qpid::Client::Session and Connection are recursively called. 490: if close fails, is xa_close going to retried? I see your point. The XA spec is silent on this and DTC documentation only refers to XA. Guarding against the possibility will be required. Overall the implementation in this file does not follow the qpid style very well. I would wrap the global variables and functions (line 91 to 190) into a DtcPlugin class to avoid global variables and functions as much as possible. At least for me, the use of the critical section rmLock is not easy to follow. Ideally thread synchronization should be encapsulated into classes (i.e. making the class thread-safe). The ResourceManager class can hold one critical section to synchronize communication with the qpid broker. The DtcPlugin class can use one critical section to synchronize access to all resource manager instances. The DtcPlugin class can implement the XA interface and the xa_switch entry methods (xa_open, xa_close, etc) can just call the DtcPlugin methods. Qpid implements a scoped lock/unlock (qpid.sys.ScopedLock) but I am not sure if you want to use it in the DTC plugin. In the trade off of addressing people familiar with COM and MSDTC versus people familiar with Qpid, I think the former makes the most sense for code maintainability. The Qpid use is practically trivial (if obscure), whereas the interaction with DTC is non-obvious and needs to be bullet proof. I would think there to be mainly scrutiny of the COM calling and callback interfaces, so sticking with a style that matches the related documentation and standard examples is probably preferable. Using the two tiered lock structure as you describe is a useful enhancement if the DTC does parallel recovery to RM instances. AmqpConnection.cpp 110 - 118: this can be refactored into DtxResourceManager. The connection should not care what needs to be done for pending transactions on connection closing. It should notify the resource manager that the connection is closing, like what it does for sessions. Agreed. This is left over cruft from another fix, and effectively a no-op. Will remove. XaTransaction.cpp 66: use InterlockedIncrement/InterlockedDecrement so you don't need this lock OK. 204: You can set the ref count to 1 in the constructor so you don't have to call AddRef() after creating each object. I think that messes with traditional coding style, at least of the sample code I've seen. I think it is easier for Qpid contributors to maintain this if the constructor is normal and the AddRef is an additional (commented) step. AmqpSession.cpp 109: why not make this a method of XaTransaction? This is a convenience casting routine, just needed by AmqpSession. I try to hide native C++ Qpid definitions from the managed .NET interfaces. 322: remove OK. In ConnectionClosed and NotifyClosed, why is it important to flush phase 0 (sending dtxEnd)? The broker is going to rollback all pending transactions of a session when it is closed. If a dtx involves multiple sessions, what is the behavior of closing one session before commit? Unfortunately, there is no way to know when a broker will execute a dtxEnd other than waiting for the command status completion. The dtxEnd can precede the prepare on the wire, but be processed
[jira] Updated: (QPID-2247) WCF AmqpChannelListener can hang for 60 seconds on close
[ https://issues.apache.org/jira/browse/QPID-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2247: --- Attachment: QPID-2247.patch Patch to provide the expected semantics when closing channel factories and listeners. Close propagates to the sub channels. Accept needs to return null when the listener is shut down. WCF AmqpChannelListener can hang for 60 seconds on close Key: QPID-2247 URL: https://issues.apache.org/jira/browse/QPID-2247 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Critical Fix For: 0.6 Attachments: QPID-2247.patch Original Estimate: 48h Remaining Estimate: 48h When closing a WCF service the ChannelListener can hang for 60 seconds, until it times out and aborts. This is known issue #3 in the Readme file. It would be nice to erradicate this for 0.6 -- 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-2128) Transaction support for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2128: --- Attachment: QPID-2128-2.patch Incorporates Xin's suggestions. Transaction support for the WCF channel --- Key: QPID-2128 URL: https://issues.apache.org/jira/browse/QPID-2128 Project: Qpid Issue Type: New Feature Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Assignee: Steve Huston Priority: Critical Fix For: 0.6 Attachments: cppbld.patch, QPID-2128-2.patch, qpid2128_1.patch, wcfbld.patch Transaction support is currently lacking from the WCF channel. As an initial implementation, full distributed transaction support from within .NET is proposed using the dtx AMQP classes and creating a plugin to the MSDTC infrastructure to drive recovery. Added performance from promotable transaction enlistment is deferred to a later date. -- 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
