Bug in POA::activate_object() ?

[Thomas Schmidt]

Hi,

I'm currently implementing some CosCollection based classes. When testing the implementation I'll receive about 20% or more BAD_OPERATION exceptions on methods sending to my collections created for tests. When debugging I found that my collection factory will receive messages (like add_element()) directed to its formerly created collection objects.

After days of debugging and code review I didn't find the reason of this failure but found a workaround:
Instead of activating my collections and other objects like collection iterators or Operations objects using POA::activate_object() which implicitly generates an ObjectId, I better use POA::activate_object_with_id(). When generating my own process-wide unique ID I'll never get BAD_OPERATIONS any more.

I'm developing and testing on MacOSX 10.8 in 32-bit memory mode using Xcode with LLVM gcc 4.2 compiler-suite.

Ciao
Thomas

--
Thomas Schmidt
Velgen 1
D-29582 Hanstedt
Tel: [phone]
Mobil: [phone]
Skype: ThCSchmidt
Email: ***@gmx.net
PGP: Key-ID: 0x810B6206

[Karel Gardas]

Hi Thomas,

this should probably be fixed on MICO HEAD by this patch:

Wed Nov 30 17:59:36 CET 2011 Karel Gardas <***@objectsecurity.com>
* fix TLS-based caching of POAObjectReference object (Rob
Ratcliff/FutureTek)
This patch fixes TLS-based caching of POAObjectReference object inside
the POA. The symptom of this issue were operations failing on some of
the invoked objects with BAD_OPERATION exception raised. This was due to
invocation being done on completely different object than it was
intended to.


please let me know if not.

Thanks,
Karel

Post by Thomas Schmidt
Hi,
I'm currently implementing some CosCollection based classes. When
testing the implementation I'll receive about 20% or more BAD_OPERATION
exceptions on methods sending to my collections created for tests. When
debugging I found that my collection factory will receive messages (like
add_element()) directed to its formerly created collection objects.
After days of debugging and code review I didn't find the reason of this
Instead of activating my collections and other objects like collection
iterators or Operations objects using POA::activate_object() which
implicitly generates an ObjectId, I better use
POA::activate_object_with_id(). When generating my own process-wide
unique ID I'll never get BAD_OPERATIONS any more.
I'm developing and testing on MacOSX 10.8 in 32-bit memory mode using
Xcode with LLVM gcc 4.2 compiler-suite.
Ciao
Thomas
--
Thomas Schmidt
Velgen 1
D-29582 Hanstedt
Tel: [phone]
Mobil: [phone]
Skype: ThCSchmidt
PGP: Key-ID: 0x810B6206
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel