[jira] [Commented] (QPID-4345) Windows memory leak
[ https://issues.apache.org/jira/browse/QPID-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (QPID-4330) windows clients hang or fault on exit (static destructors)
Cliff Jansen created QPID-4330: -- Summary: 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.18, 0.16 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] [Commented] (QPID-4071) Solaris native compiler port
[ https://issues.apache.org/jira/browse/QPID-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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] [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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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: --- Attachment: QPID-4071.patch Straightforward porting modifications to make the native compiler happy. > 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 > > 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: 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-4071) Solaris native compiler port
Cliff Jansen created QPID-4071: -- Summary: 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 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4008) tcpNoDelay connection setting causes fatal exception on Windows
[ https://issues.apache.org/jira/browse/QPID-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-4008. Resolution: Fixed Fixed: r1339927 > 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] [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] [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] [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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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] [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-tabpanel&focusedCommentId=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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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()
>
[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-tabpanel&focusedCommentId=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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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()
>
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13064385#comment-13064385
]
Cliff Jansen commented on QPID-3256:
I apologize for my lack of familiarity with mingw32.
I believe that r1145876 will fix the syntax complaints and missing mingw32
definition.
> 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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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
[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-tabpanel&focusedCommentId=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] [Updated] (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 updated QPID-3338: --- Attachment: jira-3338.patch This patch applies the MSVC variable and works properly on my Windows box using Visual studio 9. I do not have a mingw setup and would appreciate if someone who does could apply the patch and verify that the patch has no unwanted side effects for them. Thanks. > 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-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] [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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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()
>
[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-tabpanel&focusedCommentId=13052415#comment-13052415 ] Cliff Jansen commented on QPID-3256: The patch was published in the review board (https://reviews.apache.org/r/904/) where there was a comment regarding dynamic creation and deletion of the map of Qpid Thread objects: Alan Conway: Why the pointer? Just declare std::map pQpidThreads; and let std::map take care of the memory management. Andrew Stitcher: I'd also add that we don't use the hungarian variable notation either so the 'p' should be stripped (possibly from other places too) Cliff Jansen: The intended logic was that Thread::current() should have defined behavior, even if called from a static destructor. Otherwise, you need a way to guarantee the std:map destructor is never called too soon. The original JIRA's deadlock was in the context of a static destructor calling Thread::join(). On re-examiniation, the use of a non-POD lock mechanism is inconsistent with the stated goal. Thank-you for the heads up. I will work with Steve to address this and the naming problem. On yet further examination, even the PODMutex is not guaranteed to have defined behaviour during the static destructor resolution at process exit or library unload. The "static deinitialization order fiasco" has no current solution in the Boost mutex implementation (see http://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html) despite attempts to address. I see three possible ways forward: 1. Ship with the proposed fix (updated to address the review comments). It provides improved functionality, but a known potential random outage. 2. Use a Windows CRITICAL_SECTION as the mutex, and initialize and release it outside the C++ runtime in DllMain. This is a common pattern in Windows and is in fact used in the DTC plugin module in the wcf subtree. 3. Use a spin lock (via interlocked operations) to manage the exit/unload condition. Such a spin lock holds no system resources to leak and requires no explicit shutdown. This is the mechanism adopted by the Boost shared_ptr implementation of atomic operations. If anyone has a further suggestion, or a preference for option 1 please let me know. Otherwise I will put up examples of options 2 and 3 to the review board. > 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: > 1 > 21720 Main Thread Main Thread > qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal
[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-tabpanel&focusedCommentId=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
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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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.
[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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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()
[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-tabpanel&focusedCommentId=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:
> 1 > 21720 Main Thread Main Thread
> qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
> so code from file ConnectionImpl.cpp works well:
> ~IOThread() {
> std::vector threads;
> {
> ScopedLock l(threadLock);
> if (poller_)
> poller_->shutdown();
> t.swap(threads);
> }
> for (std::vector::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::cl
[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] [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-tabpanel&focusedCommentId=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] [Issue Comment Edited] (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-tabpanel&focusedCommentId=13017239#comment-13017239
]
Cliff Jansen edited comment on QPID-3193 at 4/8/11 2:28 AM:
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:
{code}
if (!mA.IsDisposed) {
// another thread calls mB.Dispose() or mA.Dispose()
mA.DoSomething();
}
{code}
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:
{code}
try {
return messagep->foo();
}
catch (const std::exception& error) {
if (someDisposedTestHere) {
throw gcnew ObjectDisposedException("Message foo");
else
throw gcnew MyException(gcnew String(error.what()));
}
{code}
I believe this should convert the null pointer (unmaged space) exception for
the user into the expected managed space exception.
[sorry, forgot the code tags]
was (Author: cliffjansen):
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 Bindin
[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-tabpanel&focusedCommentId=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] 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] Assigned: (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 reassigned QPID-2560: -- Assignee: Cliff Jansen > 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 > > 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] 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] 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] 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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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] 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] 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] 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-tabpanel&focusedCommentId=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] Commented: (QPID-2646) Qpid Messaging address support for WCF Channel
[ https://issues.apache.org/jira/browse/QPID-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876548#action_12876548 ] Cliff Jansen commented on QPID-2646: Please see the comments attached to QPID-2589. The bottom line is that the underlying new C++ messaging API provides less functionality than the older client API for 0-10 in a number of important areas. The .NET binding is necessarily similarly constrained. As I understand it, there is a desire to eventually enhance the C++ API to provide the missing bits described in the thread. But in the 0.7 time frame, this appears to be the most sensible route to add the functionality and simultaneously ease the future switch to the messaging C++ API. > 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] 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] 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-1.patch This patch provides Drain and Spout programs that operate like their existing counterparts in C++ and Python. These programs can be used to monitor the progress of addressing functionality in the WCF Channel. They can also be enhanced going forward to track map message support (coming soon). > 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 > > > 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] 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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=12867237#action_12867237 ] Cliff Jansen commented on QPID-2589: > Dictionary content = new Dictionary(); [...] > List colors = new List(); [...] > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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; isend(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-tabpanel&focusedCommentId=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] 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] 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] 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-tabpanel&focusedCommentId=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] 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] 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] Commented: (QPID-2564) Wcf functional test source file is absent
[ https://issues.apache.org/jira/browse/QPID-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863540#action_12863540 ] Cliff Jansen commented on QPID-2564: The file was missed on checkin. It is part of QPID-2359.patch. > Wcf functional test source file is absent > - > > Key: QPID-2564 > URL: https://issues.apache.org/jira/browse/QPID-2564 > Project: Qpid > Issue Type: Bug > Components: WCF/C++ Client >Affects Versions: 0.7 > Environment: Windows - any version >Reporter: Chuck Rolke >Assignee: Steve Huston > Fix For: 0.7 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > A recent update added file > qpid\wcf\test\apache\qpid\test\channel\functional\ChannelAbortCommitTest.cs > to QpidWcf.sln. But the file does not exist. > Is this file autogenerated or was is skipped on a check-in? -- 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-tabpanel&focusedCommentId=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] 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] 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-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] Updated: (QPID-2501) WCF Binding Configuration parameters
[ https://issues.apache.org/jira/browse/QPID-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2501: --- Attachment: QPID-2501.patch This patch adds functionality to specify security related binding parameters in App.config files. This patch should be applied after QPID-2500 > 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 > > Attachments: QPID-2501.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > The existing configuration capabilities of the WCF channel should be fleshed > out to handle transport level security. -- 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-2516) New sample to show how to specify WCF bindings in config files
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 -- 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-2500) Transport security for the WCF channel
[ https://issues.apache.org/jira/browse/QPID-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857881#action_12857881 ] Cliff Jansen commented on QPID-2500: Currently you have to manually update the references to Apache.Qpid.Channel.dll and Apache.Qpid.Interop.dll when building. The usual rules having the qpidclient.dll, qpidcommon.dll and the boost dlls in the right place or in your PATH apply at runtime. Since WcfPerftest also launches the native perftest.exe, it needs to be in the path or with the other dlls too. > 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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] 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-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] 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-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] 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-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-2313) Release notes for the WCF/C++ client
[ https://issues.apache.org/jira/browse/QPID-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2313: --- Attachment: QPID-2313.patch Updates to supported and planned features, build instructions, transaction configuration settings, and known issues. > Release notes for the WCF/C++ client > - > > Key: QPID-2313 > URL: https://issues.apache.org/jira/browse/QPID-2313 > Project: Qpid > Issue Type: Improvement > Components: WCF/C++ Client >Affects Versions: 0.6 > Environment: Windows >Reporter: Cliff Jansen > Fix For: 0.6 > > Attachments: QPID-2313.patch > > > Updated release notes are required for the 0.6 release. -- 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-2313) Release notes for the WCF/C++ client
Release notes for the WCF/C++ client - Key: QPID-2313 URL: https://issues.apache.org/jira/browse/QPID-2313 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Fix For: 0.6 Updated release notes are required for the 0.6 release. -- 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-2267) release artifact for WCF channel
[ https://issues.apache.org/jira/browse/QPID-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793359#action_12793359 ] Cliff Jansen commented on QPID-2267: Can it be built with just the includes and without existing qpidcommon and qpidclient binaries? I believe the WCF client requires that the cpp tree has been unzipped and built separately first. > 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 >Assignee: Andrew Stitcher > Fix For: 0.7 > > 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-2260) Build of Release configuration fails
[ https://issues.apache.org/jira/browse/QPID-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792280#action_12792280 ] Cliff Jansen commented on QPID-2260: Yes indeed. Good catch. Thanks. > 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 >Assignee: Steve Huston >Priority: Blocker > Fix For: 0.6 > > Attachments: QPID-2260-0.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > 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] Updated: (QPID-2260) Build of Release configuration fails
[ https://issues.apache.org/jira/browse/QPID-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2260: --- Attachment: QPID-2260-0.patch I inserted the logic to handle release and 64 bit builds. I also updated the Interop.dll build steps so that they mimic the steps in the CMake build of qpidclient.dll as closely as possible as a first step towards using CMake for the whole process. > 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 >Assignee: Steve Huston >Priority: Blocker > Fix For: 0.6 > > Attachments: QPID-2260-0.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > 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] 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: interop.tx.patch I'm very sorry Steve. Please revert src/Apache/Qpid/Interop/Interop.vcproj and apply this instead. > 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, interop.tx.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
[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
[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] 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-tabpanel&focusedCommentId=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 d
[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] 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] 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-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] 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] 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] Created: (QPID-2230) Interoperability test for binary and text messages
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 Environment: Windows WCF client Reporter: Cliff Jansen 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] 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=12782048#action_12782048 ] Cliff Jansen commented on QPID-2128: I would envision that the DTC plugin module is a DLL that tags along with the base client libs: qpidcommon.dll and qpidclient.dll in the base client package. The user will have to take administrative steps to enable XA transactions on his Windows machine and register the plugin with the DTC service (to run in the privileged process space). These are the same steps that would be needed for a similar database resource manager. Applications that do not use the System.Transactions .NET functionality will see no change. Applications that use transactions will encounter an exception when sending or receiving messages in the scope of an ambient transaction if they have not configured the plugin properly. 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: 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
