memory leak on CORBA component lookups in Java in EAS 5.2.0, EAS 5.3.0

We are in the process of migrating from EAS 4.2.0 to either EAS 5.2.0 or EAS
5.3.0, and, from our testing, there appears to be a small leak when calling
org.****.CORBA.ORB.string_to_object() in our Java CORBA components. The
problem is, we make such intercomponent calls in services, so the little
leak quickly becomes a big one. This was not a problem under EAS 4.2.0.

This is under a Windows environment. I don't think it's all intercomponent
calls, though:  It seems fine on one of our Java CORBA services, which calls
a shared Java CORBA component. The problem does exist in our other services.
The difference I can see is that the component being called which does leak
is a pooled Java CORBA component. (But making it shared instead of pooled
isn't an option, because it needs to several instances with different
instance variable values.)

I didn't see an EBF release to address this. Is anyone else aware of this
problem? Is there a solution? Maybe a CodeXchange fix?

As a workaround, I'm looking into caching references to other components, so
the number of calls to string_to_object() is minimized. My concern, though,
is can these references stored in instance variables on the component become
stale, which would lead to runtime failures at some point in the future? And
if so, how can I test them to see if they're valid, prior to returning them
again instead of doing a new call to string_to_object()? For instance, in
PowerBuilder, you can do an isValid() on the component handle. Is there
something similar in Java? (Ideally, I'd like to solve the problem in the
wrapper method we have that calls string_to_object(), as opposed to adding
new error handling code on every intercomponent call.)

Right now my caching strategy uses a HashMap which maps a string containing
the component name to an org.****.CORBA.Object. If the lookup in the HashMap
returns null, it makes a new call to string_to_object() and caches that in
the HashMap prior to returning it. Otherwise it returns the existing
reference from the HashMap.

Any thoughts?

Thanks,
Tom George


0 Tom 2/20/2006 3:12:04 PM
Tom:

This is the first I've heard of it.  Have you opened a bug with Sybase 
Technical support?  If so, please post the tracking number.  If not, let 
me know and I'll see if I can open one for you.  (But you might want to 
do it yourself, since you can track your own bugs but not internally 
created ones.)


Jonathan



Tom George wrote:
> We are in the process of migrating from EAS 4.2.0 to either EAS 5.2.0 or EAS
> 5.3.0, and, from our testing, there appears to be a small leak when calling
> org.****.CORBA.ORB.string_to_object() in our Java CORBA components. The
> problem is, we make such intercomponent calls in services, so the little
> leak quickly becomes a big one. This was not a problem under EAS 4.2.0.
> 
> This is under a Windows environment. I don't think it's all intercomponent
> calls, though:  It seems fine on one of our Java CORBA services, which calls
> a shared Java CORBA component. The problem does exist in our other services.
> The difference I can see is that the component being called which does leak
> is a pooled Java CORBA component. (But making it shared instead of pooled
> isn't an option, because it needs to several instances with different
> instance variable values.)
> 
> I didn't see an EBF release to address this. Is anyone else aware of this
> problem? Is there a solution? Maybe a CodeXchange fix?
> 
> As a workaround, I'm looking into caching references to other components, so
> the number of calls to string_to_object() is minimized. My concern, though,
> is can these references stored in instance variables on the component become
> stale, which would lead to runtime failures at some point in the future? And
> if so, how can I test them to see if they're valid, prior to returning them
> again instead of doing a new call to string_to_object()? For instance, in
> PowerBuilder, you can do an isValid() on the component handle. Is there
> something similar in Java? (Ideally, I'd like to solve the problem in the
> wrapper method we have that calls string_to_object(), as opposed to adding
> new error handling code on every intercomponent call.)
> 
> Right now my caching strategy uses a HashMap which maps a string containing
> the component name to an org.****.CORBA.Object. If the lookup in the HashMap
> returns null, it makes a new call to string_to_object() and caches that in
> the HashMap prior to returning it. Otherwise it returns the existing
> reference from the HashMap.
> 
> Any thoughts?
> 
> Thanks,
> Tom George
> 
> 
0 Jonathan 2/21/2006 3:56:50 PM
Jonathan,

No, I haven't opened a case yet. I thought I'd check with the group first to
see if this was a known issue.

Tom

"Jonathan Baker [Sybase]"  wrote in message
news:43fb3842$1@forums-1-dub...
> Tom:
>
> This is the first I've heard of it.  Have you opened a bug with Sybase
> Technical support?  If so, please post the tracking number.  If not, let
> me know and I'll see if I can open one for you.  (But you might want to
> do it yourself, since you can track your own bugs but not internally
> created ones.)
>
>
> Jonathan
>
>
>
> Tom George wrote:
> > We are in the process of migrating from EAS 4.2.0 to either EAS 5.2.0 or
EAS
> > 5.3.0, and, from our testing, there appears to be a small leak when
calling
> > org.****.CORBA.ORB.string_to_object() in our Java CORBA components. The
> > problem is, we make such intercomponent calls in services, so the little
> > leak quickly becomes a big one. This was not a problem under EAS 4.2.0.
> >
> > This is under a Windows environment. I don't think it's all
intercomponent
> > calls, though:  It seems fine on one of our Java CORBA services, which
calls
> > a shared Java CORBA component. The problem does exist in our other
services.
> > The difference I can see is that the component being called which does
leak
> > is a pooled Java CORBA component. (But making it shared instead of
pooled
> > isn't an option, because it needs to several instances with different
> > instance variable values.)
> >
> > I didn't see an EBF release to address this. Is anyone else aware of
this
> > problem? Is there a solution? Maybe a CodeXchange fix?
> >
> > As a workaround, I'm looking into caching references to other
components, so
> > the number of calls to string_to_object() is minimized. My concern,
though,
> > is can these references stored in instance variables on the component
become
> > stale, which would lead to runtime failures at some point in the future?
And
> > if so, how can I test them to see if they're valid, prior to returning
them
> > again instead of doing a new call to string_to_object()? For instance,
in
> > PowerBuilder, you can do an isValid() on the component handle. Is there
> > something similar in Java? (Ideally, I'd like to solve the problem in
the
> > wrapper method we have that calls string_to_object(), as opposed to
adding
> > new error handling code on every intercomponent call.)
> >
> > Right now my caching strategy uses a HashMap which maps a string
containing
> > the component name to an org.****.CORBA.Object. If the lookup in the
HashMap
> > returns null, it makes a new call to string_to_object() and caches that
in
> > the HashMap prior to returning it. Otherwise it returns the existing
> > reference from the HashMap.
> >
> > Any thoughts?
> >
> > Thanks,
> > Tom George
> >
> >


0 Tom 2/22/2006 3:07:00 PM
We opened a case with Sybase. The case number is 11207583.

Tom

"Jonathan Baker [Sybase]"  wrote in message
news:43fb3842$1@forums-1-dub...
> Tom:
>
> This is the first I've heard of it.  Have you opened a bug with Sybase
> Technical support?  If so, please post the tracking number.  If not, let
> me know and I'll see if I can open one for you.  (But you might want to
> do it yourself, since you can track your own bugs but not internally
> created ones.)
>
>
> Jonathan
>
>
>
> Tom George wrote:
> > We are in the process of migrating from EAS 4.2.0 to either EAS 5.2.0 or
EAS
> > 5.3.0, and, from our testing, there appears to be a small leak when
calling
> > org.****.CORBA.ORB.string_to_object() in our Java CORBA components. The
> > problem is, we make such intercomponent calls in services, so the little
> > leak quickly becomes a big one. This was not a problem under EAS 4.2.0.
> >
> > This is under a Windows environment. I don't think it's all
intercomponent
> > calls, though:  It seems fine on one of our Java CORBA services, which
calls
> > a shared Java CORBA component. The problem does exist in our other
services.
> > The difference I can see is that the component being called which does
leak
> > is a pooled Java CORBA component. (But making it shared instead of
pooled
> > isn't an option, because it needs to several instances with different
> > instance variable values.)
> >
> > I didn't see an EBF release to address this. Is anyone else aware of
this
> > problem? Is there a solution? Maybe a CodeXchange fix?
> >
> > As a workaround, I'm looking into caching references to other
components, so
> > the number of calls to string_to_object() is minimized. My concern,
though,
> > is can these references stored in instance variables on the component
become
> > stale, which would lead to runtime failures at some point in the future?
And
> > if so, how can I test them to see if they're valid, prior to returning
them
> > again instead of doing a new call to string_to_object()? For instance,
in
> > PowerBuilder, you can do an isValid() on the component handle. Is there
> > something similar in Java? (Ideally, I'd like to solve the problem in
the
> > wrapper method we have that calls string_to_object(), as opposed to
adding
> > new error handling code on every intercomponent call.)
> >
> > Right now my caching strategy uses a HashMap which maps a string
containing
> > the component name to an org.****.CORBA.Object. If the lookup in the
HashMap
> > returns null, it makes a new call to string_to_object() and caches that
in
> > the HashMap prior to returning it. Otherwise it returns the existing
> > reference from the HashMap.
> >
> > Any thoughts?
> >
> > Thanks,
> > Tom George
> >
> >


0 Tom 2/28/2006 5:27:41 PM
Reply:

(Thread closed)