[tao-users] TAO-ORBIX interoperability
Jacek Maslanka
ACE VERSION: 5.2, 5.2.5
ORBIX VERSION: 2000 v1.2, E2A (April 20002)
HOST MACHINE and OPERATING SYSTEM: Windows NT, 2000 SR2
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION (AND PATCHLEVEL): MSVC++ 6.0 SP5
DOES THE PROBLEM AFFECT:
COMPILATION?
no
LINKING?
no
EXECUTION?
yes
SYNOPSIS:
Transport of data from ORBIX server to TAO client seems to be impossible
when data package is larger than 2MB (using 512 MB RAM)
DESCRIPTION:
I'm trying to get sequence of "how_many" structs from ORBIX server:
CORBA::ULong how_many;
TEST::TESTStructList_var dataStructList;
TEST::TESTObject_var TESTObject1;
........................
TESTObject1->getData( how_many, dataStructList);
// test.idl
module TEST
{
struct TESTStruct
{
string label1;
...................
string label10;
};
typedef sequence<TESTStruct> TESTStructList;
interface TESTObject
{
void getData( in unsigned long how_many,
out TESTStructList dataStructList );
};
};
One struct is the size of 1KB.
Memory usage test results:
how_many memory consumption
2000 1,4 GB !
2500 windows is trying to increase paged memory ....
It looks like TAO client doesn't able to deal with message which is splited
into parts ( ORBIX splits message).
The similar problem occurs in configuration ORBIX client - TAO server:
TAO server packs all data into one message (doesn't split) and if message
size is larger than 512 KB, it is rejected by ORBIX client,
because for ORBIX it is default size of maximum data package and all larger
messages should be splited into parts (but TAO server doesn't split)
The solution in this case (tkanks to Balachandran Natarajan ) is to set
max_buffer_size in ORBIX to -1 value (unlimited size):
policies:iiop:buffer_sizes_policy:max_buffer_size = "-1";
But I have still problem with TAO client - ORBIX server configuration.
Have this configuration ever been tested for large messages?
My config.h includes:
#define ACE_NO_INLINE
#include "ace/config-win32.h"
Question:
Who is guilty? TAO or ORBIX or me?
BDW, TAO-TAO and ORBIX-ORBIX configuration works perfectly.
SAMPLE FIX/WORKAROUND:
not available
regards
Jacek
Balachandran Natarajan
On Thursday, 31 October, 2002 at 19:46:37 +0100, Jacek Maslanka wrote:
> TAO VERSION: 1.2, 1.2.5
> ACE VERSION: 5.2, 5.2.5
Thanks for using the PRF!
> ORBIX VERSION: 2000 v1.2, E2A (April 20002)
>
> HOST MACHINE and OPERATING SYSTEM: Windows NT, 2000 SR2
> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> COMPILER NAME AND VERSION (AND PATCHLEVEL): MSVC++ 6.0 SP5
>
> DOES THE PROBLEM AFFECT:
> COMPILATION?
> no
> LINKING?
> no
> EXECUTION?
> yes
>
> SYNOPSIS:
> Transport of data from ORBIX server to TAO client seems to be impossible
> when data package is larger than 2MB (using 512 MB RAM)
Could you please tell what happens? I mean does TAO client crash or
hangs or whatever???
> DESCRIPTION:
>
[snipped]
> One struct is the size of 1KB.
>
> Memory usage test results:
>
> how_many memory consumption
> 2000 1,4 GB !
> 2500 windows is trying to increase paged memory ....
>
> It looks like TAO client doesn't able to deal with message which is
> splited into parts ( ORBIX splits message).
You mean that TAO client is not able to handle fragmentation?
> The similar problem occurs in configuration ORBIX client - TAO server:
> TAO server packs all data into one message (doesn't split) and if message
> size is larger than 512 KB, it is rejected by ORBIX client,
> because for ORBIX it is default size of maximum data package and
> all larger messages should be splited into parts (but TAO server
> doesn't split) The solution in this case (tkanks to Balachandran
> Natarajan ) is to set max_buffer_size in ORBIX to -1 value
> (unlimited size):
> policies:iiop:buffer_sizes_policy:max_buffer_size = "-1";
This is a different problem and the solution is known.
> But I have still problem with TAO client - ORBIX server configuration.
> Have this configuration ever been tested for large messages?
No it doesnt seem to be tested! Could you please open up a bug report
and put your test case in? We will install a evaluation copy of ORBIX
and test this out.
> My config.h includes:
>
> #define ACE_NO_INLINE
> #include "ace/config-win32.h"
Have you seen the same problem on any other platfrom?
Thanks
Bala
Simon McQueen
These problems with TAO Client / Orbix Server using GIOP version > 1.0
fragment responses are recognised and are currently under investigation. A
bug has been raised in Bugzilla (#1349).
Cheers,
--
Simon McQueen s...@prismtechnologies.com
OpenFusion Total CORBA Solution Team www.prismtechnologies.com
Simon McQueen
Paul Calabrese
Hi,
I am also investigating some fragmentation-related problems,
although they may be different problems.
These problems appear when using Sun's Java ORB with TAO.
The Server is using Sun's orb to return large replies to a
TAO client. It appears that we are trying to hang onto
data that was allocated on the stack after it goes out of
scope. This manifests itself as a core dump in my tests.
Is it possible this could also show up as a COMM_FAILURE?
I have a fix for this, but it adds another allocation (see
changes below). I have tested my changes against an older
OCI version (OCI TAO 1.2a-p1), but think the problem remains
in all subsequent versions.
Does this also fix your problems?
Is this a reasonable change?
I think it is reasonable within the context of the current code,
which appears to do a lot of allocating and copying when handling
fragments.
Index: Transport.cpp
===================================================================
RCS file: /cvs/ocitao/ACE_wrappers/TAO/tao/Transport.cpp,v
retrieving revision 1.1.1.1.2.7
diff -u -r1.1.1.1.2.7 Transport.cpp
--- Transport.cpp 3 Oct 2002 17:11:32 -0000 1.1.1.1.2.7
+++ Transport.cpp 5 Nov 2002 16:11:03 -0000
@@ -1176,6 +1176,12 @@
}
else
{
+ // Make a deep copy, since the original buffer may
+ // be on the stack.
+ ACE_Message_Block* temp = qd->msg_block_->clone();
+ qd->msg_block_->release();
+ qd->msg_block_ = temp;
+
// if we dont have a fragment already in the queue just add it in
// the queue
this->incoming_message_queue_.enqueue_tail (qd);
--
Paul Calabrese
Object Computing Inc.
(314) 579-0066
Simon McQueen
That fix doesn't seem to help with either of the problems I'm looking at,
unfortunately.
The COMM FAILURE that occurs when a TAO client tries to process a fragmented
reply from Orbix 2k(Bug #1349) can be fixed with the following patch (in
TAO_Queued_Data::duplicate):
RCS file: /cvs/ACE_wrappers-repository/TAO/tao/Incoming_Message_Queue.cpp,v
retrieving revision 1.8
diff -r1.8 Incoming_Message_Queue.cpp
261c261
< TAO_Queued_Data (sqd.allocator_),
---
> TAO_Queued_Data (sqd),
... but the memory leak that is troubling Jacek (Bug #1356), under the same
circumstances, is still present.
Cheers,
--
Simon McQueen s...@prismtechnologies.com
OpenFusion Total CORBA Solution Team www.prismtechnologies.com
----- Original Message -----
From: "Paul Calabrese" <calab...@ociweb.com>
To: "Simon McQueen" <s...@prismtechnologies.com>
Cc: "Jacek Maslanka" <masl...@rts.com.pl>; <tao-...@cs.wustl.edu>
Sent: Tuesday, November 05, 2002 4:18 PM
Subject: Re: [tao-users] TAO-ORBIX interoperability
>
> Hi,
>
> I am also investigating some fragmentation-related problems,
> although they may be different problems.
>
> These problems appear when using Sun's Java ORB with TAO.
> The Server is using Sun's orb to return large replies to a
> TAO client. It appears that we are trying to hang onto
> data that was allocated on the stack after it goes out of
> scope. This manifests itself as a core dump in my tests.
> Is it possible this could also show up as a COMM_FAILURE?
> I have a fix for this, but it adds another allocation (see
> changes below). I have tested my changes against an older
> OCI version (OCI TAO 1.2a-p1), but think the problem remains
> in all subsequent versions.
>
> Does this also fix your problems?
> Is this a reasonable change?
>
> I think it is reasonable within the context of the current code,
> which appears to do a lot of allocating and copying when handling
> fragments.
>
<snip>