Hi Ken,
Thanks for the quick reply.
It turned out that the patch only need changes to files in glassfish,
not in Kenai.
So I made the patch with cvs again.
>> I don't need to use some Mercurial way to prepare a patch file?/
>
> It's pretty easy to handle diffs in mercurial, but I'll need to put
> together the details.
Thanks.
>> I'd like to prepare a patch for issue 6776. Could someone in the CORBA
>> team take a look at this issue first and tell me what you think? Would
>> you be interested in a patch?/
>> /_https://glassfish.dev.java.net/issues/show_bug.cgi?id=6776_
>> /
>
> Yes, I'm interested in a patch. Send me the details and I'll evaluate
> the change.
I've attached it to the issue. Looking forward to your comments.
> We need to be very careful with the Threadpool code. It's been
> problematic in many cases,
> and I have some memory leak fixes coming into the released code from a
> JDK bug.
I'm creating another thread pool, specially for outgoing IIOP requests.
I suppose that is the simplest way to prevent thread starvation and the
deadlock we're seeing.
> I assume that you are mostly interested in the GFv2 code? The GFv3 ORB
> has quite a number
> of changes, and will need a separate patch. However, a GFv2 patch could
> probably be
> directly applied to the GFv2 master repository.
I'd like it fixed in V2 code first, but I hope you will port it to V3 so
that we don't run into the issue again when we upgrade to V3.
> I think you'll also need to fill out the Sun contributor agreement, if
> you have not already
> done so.
Have done already, I'm on the signatory list.
> By the way, this is the first outside patch for CORBA in GlassFish we've
> every had, so the procedure
> needs some work :-).
Well, no need to hurry for this patch ;)
Thanks,
Dies