[omniORB] omniINSpoa and published endpoint

[Stephen Hansen]

Hi all. I'm using omniORB 4.1 and omniORBpy 3.

I have a servant that uses omniINSpoa on a specified port, with the ORB
configured via:

args = ['-ORBendPoint', 'giop:tcp::41242']
orb = CORBA.ORB_init(args, CORBA.ORB_ID)

There's a firewall between the server and the client, and 41242 is the only
port that's open. If I do a catior of the servant, I get:

omniORB: Version: 4.1.1
omniORB: Distribution date: Sun Oct 7 16:41:47 BST 2007 dgrisby
omniORB: Information: the omniDynamic library is not linked.
Type ID: "IDL:falcon.advpubtech.com/falcon/tunnel/TunnelServer:1.0"
Profiles:
1. IIOP 1.2 10.10.1.15 4265 "..u.H........."
TAG_ORB_TYPE omniORB
TAG_CODE_SETS char native code set: ISO-8859-1
char conversion code set: UTF-8
wchar native code set: UTF-16
wchar conversion code set: UTF-16

TAG_ALTERNATE_IIOP_ADDRESS 10.10.1.15 41242

My problem is when I turn omniORB's tracelevel up high, I can see that time
is continually wasted in attempting to connect to 4265 first-- and then it
falls back on using 41242. Is there any way to specify that I *only* want a
specific endpoint published in the object reference?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20081016/11030c75/attachment.htm

[Duncan Grisby]

Post by Stephen Hansen
I have a servant that uses omniINSpoa on a specified port, with the ORB
args = ['-ORBendPoint', 'giop:tcp::41242']
orb = CORBA.ORB_init(args, CORBA.ORB_ID)
There's a firewall between the server and the client, and 41242 is the only

[...]

Post by Stephen Hansen
1. IIOP 1.2 10.10.1.15 4265 "..u.H........."

[...

Post by Stephen Hansen
TAG_ALTERNATE_IIOP_ADDRESS 10.10.1.15 41242

Something else must be setting a non-specific TCP endpoint. I suspect
that you have "endPoint giop:tcp::" in your omniORB.cfg file.

Cheers,

Duncan.

[Qi, Fong]

Hi All,

I use omniORB for reference look up. My client side has about 1 million
records that need to do the look up. My IDL interface uses "struct{...}"
data. I see a few KB size memories leak each time my CORBA client call.
But 1 million of small memories leak could be huge. I have attached my
IDL file.

Any hints or guesses are greatly appreciated!

Thank you,
Fong

-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSXInterFace.idl
Type: application/octet-stream
Size: 5032 bytes
Desc: GSXInterFace.idl
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20081023/222773d9/GSXInterFace.obj

[Duncan Grisby]

Post by Qi, Fong
I use omniORB for reference look up. My client side has about 1 million
records that need to do the look up. My IDL interface uses "struct{...}"
data. I see a few KB size memories leak each time my CORBA client call.
But 1 million of small memories leak could be huge. I have attached my
IDL file.
Any hints or guesses are greatly appreciated!

Run your program under a memory checking tool like Purify or Valgrind.
That will show where the memory leaks from. It's possible that it's a
bug in omniORB, but it's also possible it's in your code.

Cheers,

Duncan.

[Qi, Fong]

Duncan,

Thank you for your help!

I did see where the memory increased. The place was generated by
"omniidl" tool, which I cannot change it. I wonder if there is a way to
fix the problem from IDL file.

Thank you,
Fong


// Local call call-back function.
static void
_0RL_lcfn_42d435b25cabde4f_30000000(omniCallDescriptor* cd, omniServant*
svnt)
{
_0RL_cd_42d435b25cabde4f_20000000* tcd =
(_0RL_cd_42d435b25cabde4f_20000000*)cd;
GSXIDL::_impl_GsxIssueInterface* impl =
(GSXIDL::_impl_GsxIssueInterface*)
svnt->_ptrToInterface(GSXIDL::GsxIssueInterface::_PD_repoId);
tcd->result = impl->getFullIssue(tcd->arg_0, tcd->arg_1.out());


}

-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: Friday, October 24, 2008 1:17 PM
To: Qi, Fong
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] IDL structure memory leak

Post by Qi, Fong
I use omniORB for reference look up. My client side has about 1

million

Post by Qi, Fong
records that need to do the look up. My IDL interface uses

"struct{...}"

Post by Qi, Fong
data. I see a few KB size memories leak each time my CORBA client

call.

Post by Qi, Fong
But 1 million of small memories leak could be huge. I have attached my
IDL file.
Any hints or guesses are greatly appreciated!

Run your program under a memory checking tool like Purify or Valgrind.
That will show where the memory leaks from. It's possible that it's a
bug in omniORB, but it's also possible it's in your code.

Cheers,

Duncan.

[Duncan Grisby]

Post by Qi, Fong
I did see where the memory increased. The place was generated by
"omniidl" tool, which I cannot change it. I wonder if there is a way to
fix the problem from IDL file.

What exactly did it say was leaked? That code you sent doesn't allocate
anything at all. It's the thing that calls your application code's
getFullIssue() method.

Duncan.

[Qi, Fong]

Hi Duncan,

The "getFullIssue()" method is I use it to get a struct data from my
CORBA server. I saw there was 2KB increasing from that place. I wonder
if there is a different way to pass the data I need.

Thank you,
Fong


-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: Friday, October 24, 2008 1:41 PM
To: Qi, Fong
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] IDL structure memory leak

Post by Qi, Fong
I did see where the memory increased. The place was generated by
"omniidl" tool, which I cannot change it. I wonder if there is a way

to

Post by Qi, Fong
fix the problem from IDL file.

What exactly did it say was leaked? That code you sent doesn't allocate
anything at all. It's the thing that calls your application code's
getFullIssue() method.

Duncan.

[Jakob Happach]

Hi Fong,

the problem you describe looks similar to an effect I encountered recently.
Can you provide me a copy of the code you use to call the getFullIssue()-Method,
starting from the point, where you create your client-instance of you interface?

The problem I encountered, was located in not storing the interface-instance in
a suitable smart pointer, so it was never released, but cyclically created again and again.

Best regards,
Jakob

-------- Original-Nachricht --------

Datum: Fri, 24 Oct 2008 13:50:54 -0400
Betreff: RE: [omniORB] IDL structure memory leak
Hi Duncan,
The "getFullIssue()" method is I use it to get a struct data from my
CORBA server. I saw there was 2KB increasing from that place. I wonder
if there is a different way to pass the data I need.
Thank you,
Fong
-----Original Message-----
Sent: Friday, October 24, 2008 1:41 PM
To: Qi, Fong
Subject: Re: [omniORB] IDL structure memory leak

Post by Qi, Fong
I did see where the memory increased. The place was generated by
"omniidl" tool, which I cannot change it. I wonder if there is a way

to

Post by Qi, Fong
fix the problem from IDL file.

What exactly did it say was leaked? That code you sent doesn't allocate
anything at all. It's the thing that calls your application code's
getFullIssue() method.
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Duncan Grisby]

Post by Qi, Fong
The "getFullIssue()" method is I use it to get a struct data from my
CORBA server. I saw there was 2KB increasing from that place. I wonder
if there is a different way to pass the data I need.

You haven't told us what your code does, so we can't possibly help you.
Most likely you have failed to follow the complex C++ mapping memory
management rules.

You say you ran your code in a memory checking tool. What exactly did it
tell you had leaked?

Duncan.