[GLASSFISH-4074] New connection cache for ORB Created: 05/Feb/08  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Blocker
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,074
Tags: 3_1-exclude

 Description   

Modify the ORB connection management to use the connection cache
in Grizzly. This fixes a number of race conditions in the current
code that can occur when a busy system is using a large number of
connections.



 Comments   
Comment by Ken Cavanaugh [ 05/Feb/08 ]

Fixed target milestone

Comment by Ken Cavanaugh [ 07/Feb/08 ]

V3 PRD

Comment by Ken Cavanaugh [ 22/Sep/09 ]

Not for v3.

Comment by Ken Cavanaugh [ 19/Jan/10 ]

Work in progress for V3.1. Note that the connection caches will be used from
the ORB workspace, not grizzly, as we still don't have sufficient resources
to do the grizzly integration.

Comment by Ken Cavanaugh [ 19/Jan/10 ]
      • Issue 7062 has been marked as a duplicate of this issue. ***
Comment by Ken Cavanaugh [ 19/Jan/10 ]
      • Issue 952 has been marked as a duplicate of this issue. ***
Comment by Ken Cavanaugh [ 14/Sep/10 ]

Moved out of release 3.1.

Comment by Ken Cavanaugh [ 06/Oct/10 ]

Some notes from Some notes from bug 6854220:

  • Would like option to periodically force connections to be closed
    after some period of inactivity (that is already present somewhere
    in the new connection design, I think).
  • Would like option to ALWAYS use fresh connection (this is available in
    HWLB plugin, but better integration would be useful).
    :
  • Would like option to periodically force connections to be closed
    after some period of inactivity (that is already present somewhere
    in the new connection design, I think).
  • Would like option to ALWAYS use fresh connection (this is available in
    HWLB plugin, but better integration would be useful).




[GLASSFISH-17013] Significant apparent regression in ORB start-up from 2.1 to 3.1.1 Created: 11/Jul/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Tim Quinn Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16543 Performance regression in JavaEE (ejb... Open
Tags: 3_1_2-exclude

 Description   

Using profiles Scott collected (with JIT turned off) for 2.1.1 and 3.1.1, I found that ORB initialization seems to show a significant regression:

Numbers are CPU seconds:

In 3.1.1:

10.527 GlassFishORBFHelper.getORB

In 2.1 is what I think is the equivalent

4.093 com.sun.enterprise.util.ORBManager.getORB

I do not have access to them right now, but IIRC other profiles with JIT turned on also showed a major regression in ORB start-up.






[GLASSFISH-17147] App client cannot find EJB behind NAT Created: 04/Aug/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1, 3.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: pablopina Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 11.04,
Sun JDK 6 u26,
GF 3.1, 3.1.1


Issue Links:
Related
is related to GLASSFISH-17151 EJB remote deployed on GF 3.1 behind ... Reopened
is related to GLASSFISH-17153 Appclient launched using JWS from any... Resolved
Tags: orb-review

 Description   

Attempting to launch an app client oever NAT

Public IP: 175.38.163.224
Private IP: 10.1.1.6
NAT on port 3700 of router to port 3700 of 10.1.1.6

In Domain.xml, i added

<jvm-options>-Dcom.sun.corba.ee.ORBVAAHost=175.38.163.224</jvm-options>
<jvm-options>-Dcom.sun.corba.ee.ORBVAAPort=3700</jvm-options>
<jvm-options>-Dcom.sun.corba.ee.ORBUserConfigurators.com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl=x</jvm-options>

Behind NAT I type in the browser

http://175.38.163.224:8080/MockEar/MockEar-app-client

Java Web Start gets launched reports

java.io.FileNotFoundException: http://175.38.163.224:8080/___JWSappclient/___system/___dyn/___system_s1...

http://www.java.net/forum/topic/glassfish/glassfish/gf-311-cant-launch-app-client-behind-nat

I've tried clearing JWS cache, the java web start folder in glassfish/domains/domain1 and redeploying but nothing.

Additionally, when setting ORBVAAHost, etc the app client doesn't launch within the local network where the server is deployed.



 Comments   
Comment by pablopina [ 05/Aug/11 ]

After another night of 'research' I feel i can be a bit more specific:

I went past the JWS error:

java.io.FileNotFoundException: http://175.38.163.224:8080/___JWSappclient/___system/___dyn/___system_s1...

Now it looks like it downloads all the jars, java console starts, the main class gets loaded, I have a
static

{ System.out.println("Class loaded") }

just before
@EJB MyEJMRemote remoteEJB;

In the console, i get to see 'Class loaded'

but then it doesn't go past there.... I've been waiting for over 10 minutes and it doesn't report error message

Comment by pablopina [ 27/Sep/11 ]

Tim,

Will this sove the issue?

http://java.net/jira/browse/GLASSFISH-17151

Comment by Tim Quinn [ 27/Sep/11 ]

It's possible that the changes described in 17151 would resolve your latest problem as well.

Are you able and interested in trying the changes described there in your environment, just as a test, to see if they resolve the problem you are seeing?

I meant to do so earlier, but given that the client is now launching properly this issue is more directly related to the ORB, so I'm going to transfer the issue to that team. It's certainly related to 17151.

I'm also changing the title of the issue to reflect the later problem.

Comment by pablopina [ 27/Sep/11 ]

Tim,

According to Blaise (the reporter of GLASSFISH-17151) they just had to rebuild orb-iiop.jar.

Now that you have reassigned it to the ORB team i'll wait a couple of days to see if they are able to respond (as I am very busy atm) and if they are unable to, yeah, i'll give it a go myself.

Comment by Harshad Vilekar [ 09/Dec/11 ]

Does this work OK with latest 3.1.2 build ? GlASSFISH-17151 is fixed in 3.1.2.





[GLASSFISH-20927] java.lang.ArrayIndexOutOfBoundsException on modifucation of the empty HashSet serialized over corba (JDK 1.7.0_u45) Created: 16/Dec/13  Updated: 03/Jun/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2, 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Peter Butkovic Assignee: russellgold
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fedora 17, Oracle JDK 1.7.0_u45


Tags: 4_0_1-evangelists, 4_0_1-reviewed

 Description   

When modifying empty HashSet that has been previously serialized over Corba, Following exception happens:

...
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1636631191
at java.util.HashMap.put(HashMap.java:498)
at java.util.HashSet.add(HashSet.java:217)
...

The reason seems to be in the one of the latest changes done in the JDK 1.7.0_u45 (I compared only to JDK 1.7.0_u25, where problem doesn't occur) within the internal implementation of the HashMap.

Namely following sections harm it:

In the HashMap:

public V put(K key, V value) {
if (table == EMPTY_TABLE)

{ inflateTable(threshold); }

...
so after the serialization / deserialization table is not equal to EMPTY_TABLE any more => won't ever call
inflateTable(threshold);
=> internal field: table won't be initialized (is empty) => later modifications fail with ArrayIndexOutOfBoundsException.

The source of the trouble seem to be optimization via introducing EMPTY_TABLE variable. However JDK expects to call readObject() on deserialization, where the reference would be fixed, corba seem to ignore it however.

See the attached test program (Arquilian with embedded glassfish 3.1.2) for reproducing the error. Simply run:
mvn test

Please note that failure comes from the:
BBean.wontWork(...)
as corba serialization already happened.

If modification is done prio to that => in:
ABean.worksOK
=> set won't be empty during corba serialization time
(commented out section)
problem won't happen.



 Comments   
Comment by Peter Butkovic [ 16/Dec/13 ]

I guess I'm not allowed to attach anything Well, that's weird.

Anyway, the test case is available on github: https://github.com/typekpb/GLASSFISH-20927

to reproduce, go for the:
git clone https://github.com/typekpb/GLASSFISH-20927 GLASSFISH-20927
cd GLASSFISH-20927
mvn test

Just make sure to test with the Oracle JDK 1.7.0_u45

Comment by mduigou [ 17/Dec/13 ]

See also GLASSFISH-20814 which is related.

Comment by russgold [ 20/Dec/13 ]

I can duplicate it using your test case. What I don't seem to be able to do is attach a debugger to server process in which the failure is happening - that could be related by lack of familiarity with Arquillian.

Comment by Peter Butkovic [ 21/Dec/13 ]

would this work for you? http://arquillian.org/guides/getting_started/#debug_the_test

Comment by russgold [ 24/Dec/13 ]

This is actually the same issue as GLASSFISH-20814; We will fix it in GF 4 and then look into back porting. Further comments will be found on the other bug.





[GLASSFISH-20839] Corba: GF QL failing with JDK7U25: java.security.AccessControlException Created: 01/Oct/13  Updated: 01/Oct/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Joe Di Pol Assignee: russgold
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GF full profile QL fails with this exception when
running with JDK7U25. When running with JDK7U09, the failure
does not occur.

Logs here:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-build-continuous/14626/
Results here:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-build-continuous/14626/testReport/

It looks like the error is coming from Corba.

Caused by: java.rmi.RemoteException: ; nested exception is:
java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:142)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
... 93 more
Caused by: java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at org.omg.CORBA_2_3.portable.OutputStream.checkPermission(OutputStream.java:65)
at org.omg.CORBA_2_3.portable.OutputStream.<init>(OutputStream.java:81)
at com.sun.corba.ee.impl.encoding.CDROutputObject.<init>(CDROutputObject.java:136)
at com.sun.corba.ee.impl.encoding.EncapsOutputStream.<init>(EncapsOutputStream.java:97)
at com.sun.corba.ee.impl.encoding.EncapsOutputStream.<init>(EncapsOutputStream.java:89)
at com.sun.corba.ee.impl.orb.ORBImpl.create_output_stream(ORBImpl.java:706)
at com.sun.corba.ee.impl.corba.AnyImpl.create_input_stream(AnyImpl.java:544)
at org.omg.CosTransactions.OTSPolicyValueHelper.extract(OTSPolicyValueHelper.java:25)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:253)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:290)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:378)
at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.beginRequest(ClientRequestDispatcherImpl.java:324)
at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.request(ClientDelegateImpl.java:227)
at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.is_a(ClientDelegateImpl.java:392)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:490)
at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:541)
at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:519)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.enterprise.naming.util.IIOPObjectFactory.getObjectInstance(IIOPObjectFactory.java:71)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:133)
... 94 more
]]



 Comments   
Comment by Joe Di Pol [ 01/Oct/13 ]

Comments from JDK team:

we fixed a vulnerability in JDK code around the org.omg.CORBA_2_3.portable.OutputStream class (7u25 fix). Any code extending that class will now need extra permission check if a security manager is installed.

There is a property flag to allow subclass instantiations without the security check (jdk.corba.allowOutputStreamSubclass=true)





[GLASSFISH-18405] ejb lookup failed from netbeans 7.0 based ejb-client with glassfish 3.1.1 Created: 24/Feb/12  Updated: 11/Jul/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: olafj Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System = Mac OS X version 10.7.3 running on x86_64
Java; VM; Vendor = 1.6.0_29; Java HotSpot(TM) 64-Bit Server VM 20.4-b02-402; Apple Inc.
Runtime = Java(TM) SE Runtime Environment 1.6.0_29-b11-402-11D50b


Attachments: Text File messages.log     Text File messages.log     Zip Archive TestEJB.zip     Zip Archive TestNB.zip    
Tags: ejb, glassfish, glassfish-3-1-1, netbeans

 Description   

An exception occurs at first try to lookup for an remote ejb facade, same client works with same ejb-modules hosted on glassfish 3.0.1:

java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:262)
Caused: java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated starting from SystemClassLoader[62 modules] with possible defining loaders null and declared parents [ModuleCL@61f52b85[de.crosssoft.usradm.CSBenutzerverwaltung.Data], ModuleCL@1830e4a7[org.netbeans.modules.settings], ModuleCL@7ec78e02[org.netbeans.core.output2], ModuleCL@4f50f0e2[org.openide.explorer], ModuleCL@7595ddb5[org.netbeans.modules.options.keymap], ModuleCL@2e1ed620[org.netbeans.modules.keyring], ModuleCL@7ba76fdd[org.netbeans.core.ui], ModuleCL@3f2620b5[de.crosssoft.CSBaseGuiUtilModule], ModuleCL@75787005[org.netbeans.modules.favorites], ModuleCL@45ed957d[org.netbeans.core.windows], ...47 more]
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:264)
at org.netbeans.ModuleManager$SystemClassLoader.loadClass(ModuleManager.java:557)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:234)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:73)
Caused: org.omg.CORBA.BAD_OPERATION: FEIN: IOP01210035: ClassNotFoundException while attempting to load interface com.sun.ejb.codegen.GenericEJBHome_Generated vmcid: OMG minor code: 35 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy31.classNotFound3(Unknown Source)
at com.sun.corba.ee.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:76)
at com.sun.corba.ee.impl.util.Utility.loadStub(Utility.java:835)
Caused: org.omg.CORBA.BAD_OPERATION: WARNUNG: IOP01211205: Exception in loadStub vmcid: OMG minor code: 1205 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[catch] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy54.exceptionInLoadStub(Unknown Source)
at com.sun.corba.ee.impl.util.Utility.loadStub(Utility.java:842)
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:252)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:406)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
...



 Comments   
Comment by Sanjeeb Sahoo [ 24/Feb/12 ]

transfer to ejb container

Comment by olafj [ 10/Apr/12 ]

Is there any progress on this issue? Can i help with more information? Are there other related issues?

Comment by marina vatkina [ 10/Apr/12 ]

Please attach a test case.

Comment by olafj [ 12/Jun/12 ]

Attached a testcase: EJB-Module, Netbeans Platform Application. Error still occurs with Netbeans Platform 7.0 and Glassfish 3.1.2

Comment by olafj [ 19/Jun/12 ]

Is there any progress on this issue? Do you need more information? Can i help to clearify open questions?

Comment by marina vatkina [ 19/Jun/12 ]

Please provide the exact steps on how to reproduce the error.

Comment by olafj [ 20/Jun/12 ]

Thats very simple.

Build and deploy ejb-project.
Build and run client-project (netbeans platform app).
After app-startup a top component with a "jbutton1" is open. button's click event handler tries to get an initial context and tries call a function of a remote stateless session bean.
Ejb-request fails.

Comment by marina vatkina [ 21/Jun/12 ]

Assigning to ORB module to check why the just loaded class can't be found.

Comment by olafj [ 03/Jul/12 ]

Any new ideas? How can i help?
Without a solution we can not proceed with development. We are going to migrate to Java 7 and Netbeans 7.2, but without an upgrade to Glassfish 3.1.2 that makes no sense for us.

Comment by olafj [ 11/Jul/12 ]

Can you please tell me the status quo of this issue?





[GLASSFISH-17151] EJB remote deployed on GF 3.1 behind a NAT unaccessible via a simple Java app Created: 05/Aug/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: Blaise Gosselin Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS Linux Debian 6
JDK 1.6.0.26


Issue Links:
Related
is related to GLASSFISH-17147 App client cannot find EJB behind NAT Open
Tags: 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes, orb-review

 Description   

I have 2 Glassfish servers version 3.1: a FRONT server and a BACK server.
The FRONT server is in a DMZ.
The BACK server is in on a private lan, not accessible directly from the DMZ, but through a firewall that does a NAT on the IP of the BACK server.
-> IP-PU-B = Public IP address of the BACK
-> IP-PR-B = Private IP address of the BACK

Thus, the FRONT server only knows the public IP of the BACK server (the "NATed" IP). The Glassfish on the BACK server knows only its own "private" IP address, not its NATed address (it is only valid for machines on the DMZ).

Here is my client code:
try {
InitialContext context = new InitialContext();
System.out.println("Context initialized!");
HelloService service = (HelloService) context.lookup("HelloEJB");
System.out.println("Service retrieved!");
String name = service.countryCount();
System.out.println("Hello " + name);
} catch (Exception e) {
e.printStackTrace();
}

And here is my jndi.properties content in my client app:
java.naming.factory.initial = com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs = com.sun.enterprise.naming
java.naming.factory.state = com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
org.omg.CORBA.ORBInitialHost = IP-PU-B
org.omg.CORBA.ORBInitialPort = 3700

This code doesn't work if I launch my application from the DMZ trying to access the EJB remote via the IP address IP-PU-B.
This code works if I launch the application from "inside the network" trying to access the EJB remote via the IP address IP-PR-B.

The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall.

We have already tried the following solutions:

  • Connecting to a Remote EJB Module Through a Firewall
    Link: http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesud/index.html
    We have put the IP-PU-B as value for the variable "com.sun.corba.ee.ORBVAAHost".
    In that case, the problem between the FRONT and the BACK still exists, and moreover there is also a problem when I try to access the EJB remote from the Java application run on the BACK to the EJB remote on the BACK.
  • Replace Network address of the orb-listener-1, no better result.
  • Use of variable "java.rmi.server.hostname", no better result.

Is there a specific way to configure Glassfish behind a NAT to make it send the public IP instead of the private one?

Thanks in advance for your help!



 Comments   
Comment by Blaise Gosselin [ 09/Aug/11 ]

Important info: I just tested with the version 3.0.1, and it works correctly when I change the "Network address" of the "orb-listener-1".

It must then be a regression...

Comment by Nicolasdew [ 14/Sep/11 ]

Hello everyone,

we are experiencing the same problem using glassfish 3.1.1
The weirdest thing when setting the parameter com.sun.corba.ee.ORBVAAHost = "our_public_address" is that sometimes i can see that this address is taken into account and sometimes not.
I can see that by analyzing the GIOP packet on wireshark.
Is it confirmed that it is a regression or a misuse ?
Thank you for your reply.

Comment by Blaise Gosselin [ 22/Sep/11 ]

Hi,

Is it possible to have an answer to this problem please?

We are currently facing CDI problems with version 3.0.1, while it is the only one that works through a firewall => WE ARE STUCK for the moment, and we will probably have to use another AS (such as JBoss) if one solution is not proposed/found to our issues! At least maybe you could indicate us the class/lib to change in the GF 3.1 to make it work through a firewall as expected!

Thanks in advance for your help!

KR,

Comment by Blaise Gosselin [ 27/Sep/11 ]

Good news: we have solved this issue by our-self!

A colleague of mine has investigated in the Glassfish source, and here is the result.

Modifications in org.glassfish.enterprise.iiop.impl.GlassFishORBManager:

  1. Change method getClearTextIiopListener to test the “security-enabled” attribute of the iiop-listener (our clear text listener had an SSL element, probably set by the administration console…).
GlassFishORBManager.java
    private IiopListener getClearTextIiopListener() {
        if (iiopListeners != null)  {
            for (IiopListener il : iiopListeners) {
                if (!"true".equals(il.getSecurityEnabled())) {
                    return il ;
                }
            }
        }
		
        return null ;
    }
  1. Change the checkForAddrAny method to set the ORBConstants.SERVER_HOST_PROPERTY property to orbInitialHost. This allows us to send the hostname to the front server, and not the un-NATed IP. This is the same behavior as in Glassfish 3.0, and is needed in our case (natted network between the EJB server and the client).
GlassFishORBManager.java
    private String checkForAddrAny(Properties props, String orbInitialHost) {
        if ((orbInitialHost.equals("0.0.0.0")) || (orbInitialHost.equals("::"))
                || (orbInitialHost.equals("::ffff:0.0.0.0"))) {
            try {
                String localAddress = java.net.InetAddress.getLocalHost().getHostAddress();
                return localAddress;
            } catch (java.net.UnknownHostException uhe) {
                logger.log(Level.WARNING,
                    "Unknown host exception - Setting host to localhost");
				
                return DEFAULT_ORB_INIT_HOST;
            }
        } else {
            props.setProperty(ORBConstants.SERVER_HOST_PROPERTY, orbInitialHost);
            return orbInitialHost;
        }
    }

That's it!

Comment by Harshad Vilekar [ 15/Oct/11 ]

The fix is putback to 3.1.2 workspace. Blaise, could you please confirm if the issue is resolved in (tonight's or later) 3.1.2 build ?

First change was not required - getSsl() correctly returns null for ClearTextIiopListener. Please check you admin settings if there is issue.

Comment by Harshad Vilekar [ 16/Nov/11 ]

The fix is verified by the reporter.

Comment by Harshad Vilekar [ 16/Dec/11 ]

Although the fix works with NAT, it has a side effect - resulting in regression (GLASSFISH-17689). Fix is reverted.

Comment by mone_java [ 24/Jan/12 ]

I have the same problem.... I tried with glassfish 3.1.2-b19-01_23_2012....

this is what my client sends to the server (wireshark):

0000 00 13 49 e2 a3 e9 f4 6d 04 16 75 5e 08 00 45 00 ..I....m ..u^..E.
0010 01 60 ad b9 40 00 40 06 6b 86 c0 a8 01 23 4f 0e .`..@.@. k....#O.
0020 0f 7f c3 9e 0e 75 34 13 d6 8c 7e 5c 1a d8 80 18 .....u4. ..~\....
0030 00 5c 21 ab 00 00 01 01 08 0a 00 37 7b 6c 00 23 .!..... ...7{l.#
0040 e1 d3 47 49 4f 50 01 02 00 00 00 00 01 20 00 00 ..GIOP.. ..... ..
0050 00 05 03 00 00 00 00 00 00 00 00 00 00 0b 4e 61 ........ ......Na
0060 6d 65 53 65 72 76 69 63 65 00 00 00 00 06 5f 69 meServic e....._i
0070 73 5f 61 00 00 00 00 00 00 03 00 00 00 11 00 00 s_a..... ........
0080 00 02 00 02 00 00 4e 45 4f 00 00 00 00 02 00 14 ......NE O.......
0090 00 00 00 00 00 06 00 00 00 a6 00 00 00 00 00 00 ........ ........
00a0 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f 53 65 .(IDL:om g.org/Se
00b0 6e 64 69 6e 67 43 6f 6e 74 65 78 74 2f 43 6f 64 ndingCon text/Cod
00c0 65 42 61 73 65 3a 31 2e 30 00 00 00 00 01 00 00 eBase:1. 0.......
00d0 00 00 00 00 00 6a 00 01 02 00 00 00 00 0a 31 32 .....j.. ......12
00e0 37 2e 30 2e 31 2e 31 00 95 21 00 00 00 19 af ab 7.0.1.1. .!......
00f0 cb 00 00 00 00 02 00 00 00 65 00 00 00 08 00 00 ........ .e......
0100 00 00 00 00 00 00 14 00 00 00 00 00 00 02 00 00 ........ ........
0110 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0120 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0130 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......
0140 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0150 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
0160 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 ngContex t:1.0.

and this what my server sends to my client:

0000 f4 6d 04 16 75 5e 00 13 49 e2 a3 e9 08 00 45 00 .m..u^.. I.....E.
0010 02 72 fb 33 40 00 33 06 29 fa 4f 0e 0f 7f c0 a8 .r.3@.3. ).O.....
0020 01 23 0e 75 c3 9e 7e 5c 1a d8 34 13 d7 b8 80 18 .#.u..~\ ..4.....
0030 00 6c cf 72 00 00 01 01 08 0a 00 23 e2 05 00 37 .l.r.... ...#...7
0040 7b 6c 47 49 4f 50 01 02 00 01 00 00 02 32 00 00 {lGIOP.. .....2..
0050 00 05 00 00 00 03 00 00 00 02 4e 45 4f 00 00 00 ........ ..NEO...
0060 00 02 00 14 00 00 00 00 00 06 00 00 01 30 00 00 ........ .....0..
0070 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0080 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 78 74 g/Sendin gContext
0090 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 00 00 /CodeBas e:1.0...
00a0 00 01 00 00 00 00 00 00 00 f4 00 01 02 00 00 00 ........ ........
00b0 00 0e 31 39 32 2e 31 36 38 2e 31 2e 32 30 32 00 ..192.16 8.1.202.
00c0 0e 74 00 00 00 19 af ab cb 00 00 00 00 02 00 00 .t...... ........
00d0 00 64 00 00 00 08 00 00 00 00 00 00 00 00 14 00 .d...... ........
00e0 00 00 00 00 00 03 00 00 00 01 00 00 00 20 00 00 ........ ..... ..
00f0 00 00 00 01 00 01 00 00 00 02 05 01 00 01 00 01 ........ ........
0100 00 20 00 01 01 09 00 00 00 01 00 01 01 00 00 00 . ...... ........
0110 00 26 00 00 00 02 00 02 00 00 00 00 00 21 00 00 .&...... .....!..
0120 00 7c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 .|...... ........
0130 00 24 00 00 00 20 00 00 00 66 00 00 00 00 00 00 .$... .. .f......
0140 00 01 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
0150 32 30 32 00 0e ec 00 40 00 00 00 00 00 08 06 06 202....@ ........
0160 67 81 02 01 01 01 00 00 00 17 04 01 00 08 06 06 g....... ........
0170 67 81 02 01 01 01 00 00 00 07 64 65 66 61 75 6c g....... ..defaul
0180 74 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 t....... ........
0190 00 08 06 06 67 81 02 01 01 01 00 00 00 0f 00 00 ....g... ........
01a0 00 00 00 00 00 2b 49 44 4c 3a 6f 6d 67 2e 6f 72 .....+ID L:omg.or
01b0 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
01c0 6e 67 43 6f 6e 74 65 78 74 45 78 74 3a 31 2e 30 ngContex tExt:1.0
01d0 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 00 01 ........ ........
01e0 02 00 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
01f0 32 30 32 00 0e 74 00 00 00 4d af ab cb 00 00 00 202..t.. .M......
0200 00 20 00 00 00 64 00 00 00 09 53 31 41 53 2d 4f . ...d.. ..S1AS-O
0210 52 42 00 00 00 00 00 00 00 02 00 00 00 08 52 6f RB...... ......Ro
0220 6f 74 50 4f 41 00 00 00 00 0d 54 4e 61 6d 65 53 otPOA... ..TNameS
0230 65 72 76 69 63 65 00 00 00 00 00 00 00 08 00 00 ervice.. ........
0240 00 01 00 00 00 01 14 00 00 00 00 00 00 02 00 00 ........ ........
0250 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0260 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0270 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......

As you can see the server send to my client the private IP and not the public.... I don't understand what i can do for resolve this....
Thank you a lot!

set the public IP as IP for IIOP listener, will that not solve the problem ?

Comment by Rebecca Parks [ 24/Jan/12 ]

This has been flagged for the 3.1.2 Release Notes, but I'm not sure what the Release Notes should say. I think I understand the problem, which is summed up in this paragraph:

"The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall."

What I'm not sure I understand is the workaround. Is it the code that Blaise posted?

Comment by Harshad Vilekar [ 25/Jan/12 ]

There is no properly tested workaround available for this issue.

Comment by mone_java [ 25/Jan/12 ]

So for now, it is impossible to communicate with an EJB on a server debian? I have not tried it with windows server ... The code of Blaise Gosselin has been applied, or has been removed? Otherwise for now try with that code, because I need it to work!

ps And another question... Why the client sends to the server 127.0.1.1 ?

Comment by mone_java [ 29/Jan/12 ]

I tried the version 3.1.2_b06 but does not work.... What is your setting of the iiop listener?

Comment by thezebulette [ 16/Apr/12 ]

hello
I think I had the same problem trying to deploy my Eclipse RCP application ( EJB3 inside )

I don't have any problem accesing glassfish server on private adress
I can't ( and I had try all) calling my application on public adress outside the DMZ ..

What are the clue in fine ? any

Comment by ymajoros [ 15/Jan/13 ]

Hi,

Is it possible to have an answer to this problem please?

I work with Blaise Gosselin, who made the patch in #4, and we still have the issue. We have to patch every new version of Glassfish as described.

Thanks in advance for your help!

KR,

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

Comment by hoseka [ 22/Apr/13 ]

Hi all!
Can I solve this problem in version 3.1.2?
Does the correction proposed by Blaise Gosselin work?
Where can I get the source orb-iiop.jar to fix it and replace in my glassfish?

Comment by skgaju [ 05/Sep/13 ]

has anyone tried setting public IP to IIOP listener and Blaise Gosselin patch.





[GLASSFISH-11942] CORBA monitoring work Created: 19/May/10  Updated: 21/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: future release
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,942
Tags: 3_1-exclude, monitoring

 Description   

See http://kenai.com/projects/gf-corba-v3-mirror/pages/CorbaMonitoring for
details.



 Comments   
Comment by Ken Cavanaugh [ 19/May/10 ]

Should be enhancement.

Comment by Ken Cavanaugh [ 25/Aug/10 ]

Removed from GF 3.1.





[GLASSFISH-4073] Move CORBA transport to Grizzly Created: 05/Feb/08  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Critical
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,073
Tags: 3_1-exclude

 Description   

Move the ORB NIO transport to use Grizzly. This will take advantage
of ongoing optimization work in grizzly, and enable new features such as
port unification.



 Comments   
Comment by Ken Cavanaugh [ 05/Feb/08 ]

Fixed incorrect summary.

Comment by Ken Cavanaugh [ 05/Feb/08 ]

Corrected target milestone

Comment by Ken Cavanaugh [ 05/Feb/08 ]

Fixed platform.

Comment by Ken Cavanaugh [ 07/Feb/08 ]

Three phases:

1. Move ORB to Grizzly transport.
2. Replace old ORB connection caches with Grizzly versions.
3. Move CSIv2 impl to Grizzly SSL transport.

Phase 1 is nearly complete.

Comment by Ken Cavanaugh [ 22/Sep/09 ]

Not for V3.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Probably won't happen in v3.1 either, but moving to v3.1 for now.
This is still a long-term goal, but lack of resources makes for slow progress.

Comment by Ken Cavanaugh [ 22/Apr/10 ]

This is not in the PRD for GF 3.1.

Comment by Ken Cavanaugh [ 25/Aug/10 ]

Moved out of GF 3.1 release.

Comment by jthoennes [ 23/Mar/12 ]

Hello,

will this be implemented for GF 4.0?

That would be great.

Cheers, Jörg





[GLASSFISH-17449] Redeploy memory leak Created: 20/Oct/11  Updated: 11/Jun/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: jelinj14 Assignee: russgold
Resolution: Unresolved Votes: 12
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

windows 7, 64bit


Attachments: File keepalive-ref.tiff     File runtest.sh    
Tags: 3_1_2-exclude, 4_0_1-approved, 4_0_1-evangelists, memoryleak, orb-review, redeploy

 Description   

Redeployment causes memory leaks, using jmap and jhat can resolve for example: org.glassfish.javaee.full.deployment.EarClassLoader this class has instance each deploy and undeploy even if app is undeployed



 Comments   
Comment by Hong Zhang [ 21/Oct/11 ]

Assign to tim to take a look as he has done a lot of work of tracking down memory leak in 3.1.1.

Comment by Tim Quinn [ 21/Oct/11 ]

I was able to reproduce the problem.

I deployed a simple EAR (containing an EJB) 100 times, and saw 100 EarClassLoader instances remaining live, even after forcing GCs using jconsole.

(I will attach the simple shell script I used.)

Run the script, then browse to http://localhost:7000.

At least part of the problem seems to be caused by EJB monitoring retaining a reference to each StatelessSessionContainer, which in turn has a reference to EarClassLoader.

I am transferring this to the EJB team for investigation into cleaning up the references from monitoring when a container is retired.

Comment by Tim Quinn [ 21/Oct/11 ]

Attached runtest.sh for repeatedly deploying an app and monitoring memory usage.

Comment by jelinj14 [ 21/Oct/11 ]

When the application is bigger, (I have about 70 stateless session beans on EJB side) it causes big memory leak, every deploy is about 90MB leaks. But I'm not sure whether is it only EarClassLoader.
Thanks for resolve.

Comment by Tim Quinn [ 21/Oct/11 ]

There might well be other issues besides the one I found so far. Once that one is resolved we will look into this again for other leaks.

Comment by Cheng Fang [ 25/Oct/11 ]

Hi Tim, I tried your script with my test EAR on trunk build, and had different results. After finishing your script (100 deploy/undeploy), the result page shows only 3 instances of EarClassLoader.

I then tried deployed/undeploy one by one, and also shows any time after GC, the count is at most 3. The small number of left over instances could be related to annotation processing tasks.

Comment by Tim Quinn [ 25/Oct/11 ]

Cheng,

Perhaps something has changed between 3.1.1 and 4.0 (trunk) then. (I do not have a chance right now to try it myself on the trunk.)

Can whatever the change is be back-ported to 3.1.2? (I realize that requires understanding what change(s) are responsible for the better behavior in 4.0).

Comment by Cheng Fang [ 25/Oct/11 ]

Related to http://java.net/jira/browse/GLASSFISH-17468 (WebappClassLoader leak after undeployment)

Comment by Cheng Fang [ 03/Nov/11 ]

Once issue 17468 is resolved, it will help eliminate some causes of leaks.

Another source of leaks, when deploying apps with remote ejb, is from orb layer. An instance of com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive holds a reference to the EarClassLoader after undeploy.

Comment by Cheng Fang [ 03/Nov/11 ]

Attached a screen shot of reference from com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive

Comment by Cheng Fang [ 03/Nov/11 ]

re-assign to orb team to evaluate if we can reset the context class loader when creating the KeepAlive thread, to avoid inheriting the app class loader from the parent thread.

Comment by notabenem [ 02/Dec/13 ]

Just run into this on Glassfish 4: com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive prevents the EAR from being garbage collected.
This pretty much eliminates the possibility of a reliable reloading mechanism (Continuous delivery)

Comment by electricsam [ 15/Jan/14 ]

I too can confirm that this is occurring in Glassfish 4.0

Comment by electricsam [ 30/Jan/14 ]

I've investigated a workaround until this is fixed. I found references to the current EarClassLoader (to be undeployed) in the following locations:

1. contextClassLoader in various threads
2. Direct references in ThreadLocals in varous threads
3. A contextClassLoader reference in the selector thread of the following field heirerchy: thread.orb.transportManager.selector
4. A contextClassLoader reference in the static resyncThread field of the com.sun.jts.CosTransactions.RecoveryManager class
5. Lots of indirect references in the ThreadLocals in the admin-listener threads

The below listed code will attempt to clean up items 1-3 when an app is undeployed (or redeployed).

For item 4, I was unable to get a reference to the RecoveryManager that had a contextClassLoader reference, but it is static and not as bad as a thread pool issue.

For item 5, the number of references and the object hierarchy depth made a workaround difficult. My best attempt was to limit the pool size for the admin-thread-pool to 5 with a min of 0 and a timeout of 0 (Although, I never see the pool shrink after it reaches capacity). There is still a leak here, but does not seem to grow past a certain point.

Hopefully this will help the GF dev that looks at this issue or any GF users with the same problem until then.

Bar.java
package test;

import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Singleton
@Startup
public abstract class ClassLoaderCleaner {

    private static final Logger logger = Logger.getLogger(ClassLoaderCleaner.class.getName());

    private ClassLoader loader = null;

    @PreDestroy
    protected void destroy() {
        try {
            loader = getClass().getClassLoader();
            cleanUp();
        } catch (Throwable e) {
            logger.log(Level.SEVERE, null, e);
        }
    }

    private void cleanUp() {
        Thread[] threads = getThreads();
        for (Thread thread : threads) {
            if (thread != null) {
                cleanContextClassLoader(thread);
                cleanOrb(thread);
                cleanThreadLocal(thread);

            }

        }
    }
    
        private Thread[] getThreads() {
        ThreadGroup rootGroup = Thread.currentThread().getThreadGroup();
        ThreadGroup parentGroup;
        while ((parentGroup = rootGroup.getParent()) != null) {
            rootGroup = parentGroup;
        }

        Thread[] threads = new Thread[rootGroup.activeCount()];
        while (rootGroup.enumerate(threads, true) == threads.length) {
            threads = new Thread[threads.length * 2];
        }
        return threads;
    }

    private boolean loaderRemovable(ClassLoader cl) {
        if (cl == null) {
            return false;
        }
        Object isDoneCalled = getObject(cl, "doneCalled");
        if (cl.getClass().getName().equals(loader.getClass().getName())
                && isDoneCalled instanceof Boolean && (Boolean) isDoneCalled) {
            return true;
        }
        return loader == cl;
    }

    private Field getField(Class clazz, String fieldName) {
        Field f = null;
        try {
            f = clazz.getDeclaredField(fieldName);
        } catch (NoSuchFieldException ex) {

        } catch (SecurityException ex) {
            logger.log(Level.WARNING, "Unable to get field " + fieldName + " on " + clazz.getName(), ex);
        }

        if (f == null) {
            Class parent = clazz.getSuperclass();
            if (parent != null) {
                f = getField(parent, fieldName);
            }
        }
        if (f != null) {
            f.setAccessible(true);
        }
        return f;
    }

    private Object getObject(Object instance, String fieldName) {
        Class clazz = instance.getClass();
        Field f = getField(clazz, fieldName);
        if (f != null) {
            try {
                return f.get(instance);
            } catch (IllegalArgumentException | IllegalAccessException ex) {
                logger.log(Level.WARNING, "Unable to get " + fieldName + " on " + clazz.getName(), ex);
            }
        }
        return null;
    }

    private void cleanContextClassLoader(Thread thread) {
        if (loaderRemovable(thread.getContextClassLoader())) {
            thread.setContextClassLoader(null);
            logger.log(Level.INFO, "Cleaned context classloader {0}", thread.getName());
        }
    }

    private void cleanOrb(Thread thread) {
        Object currentWork = getObject(thread, "currentWork");
        if (currentWork != null) {
            Object orb = getObject(currentWork, "orb");
            if (orb != null) {
                Object transportManager = getObject(orb, "transportManager");
                if (transportManager != null) {
                    Thread selector = (Thread) getObject(transportManager, "selector");
                    if (selector != null && loaderRemovable(selector.getContextClassLoader())) {
                        selector.setContextClassLoader(null);
                        logger.log(Level.INFO, "Cleaned orb ref {0}", thread.getName());
                    }
                }
            }
        }
    }

    private void removeThreadLocal(Object entry, Object threadLocals, Thread thread) {
        ThreadLocal threadLocal = (ThreadLocal) getObject(entry, "referent");
        if (threadLocal != null) {
            Class clazz = null;
            try {
                clazz = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
            } catch (ClassNotFoundException ex) {
                logger.log(Level.WARNING, null, ex);
            }
            if (clazz != null) {
                Method removeMethod = null;
                Method[] methods = clazz.getDeclaredMethods();
                if (methods != null) {
                    for (Method method : methods) {
                        if (method.getName().equals("remove")) {
                            removeMethod = method;
                            removeMethod.setAccessible(true);
                            break;
                        }
                    }
                }
                if (removeMethod != null) {
                    try {
                        removeMethod.invoke(threadLocals, threadLocal);
                        logger.log(Level.INFO, "Cleaned threadlocal {0}", thread.getName());
                    } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                        logger.log(Level.SEVERE, null, ex);
                    }
                }

            }

        }
    }

    private void cleanThreadLocal(Thread thread) {
        Object threadLocals = getObject(thread, "threadLocals");
        if (threadLocals != null) {
            Object table = getObject(threadLocals, "table");
            if (table != null) {
                int size = Array.getLength(table);
                for (int i = 0; i < size; i++) {
                    Object entry = Array.get(table, i);
                    if (entry != null) {
                        Field valueField = getField(entry.getClass(), "value");
                        if (valueField != null) {
                            try {
                                Object value = valueField.get(entry);
                                if (value != null && value instanceof ClassLoader && loaderRemovable((ClassLoader) value)) {
                                    removeThreadLocal(entry, threadLocals, thread);
                                }
                            } catch (IllegalArgumentException | IllegalAccessException ex) {
                                logger.log(Level.WARNING, "Unable to get threadlocal value", ex);
                            }

                        }
                    }

                }
            }
        }
    }

}
Comment by Ed Bratt [ 20/May/14 ]

Assigned FYI ...

Comment by russgold [ 11/Jun/14 ]

If, as notabenem says, it is the KeepAlive objects preventing the garbage collection, that suggests that deploying the EAR is calling javax.rmi.CORBA.registerTarget, but undeploying is not calling javax.rmi/CORBA.unexportObject for each of the remote objects.

I'm going to look through the source to see where this is being called.





[GLASSFISH-16321] Improve Hudson testing of ORB Created: 06/Apr/11  Updated: 08/Dec/11

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We are working on a number of improvements for automated ORB testing using Hudson:

  • Split the main Hudson job into separate build and ORB regression test jobs
  • This requires testing against delivered artifacts instead of the build classes in the workspace
    Fixing this requires some changes (ken is working on these):
  • Create a test/orb directory for the artifacts to test against
  • Have the ORB build automatically copy build/release/lib/bundles/*jar to test/orb
  • Modify test classpath accordingly
  • Package ORB activation/ORBD code in a bundle for testing purposes
  • Package IDL compiler in a bundle for testing purposes
  • Anything else that breaks the tests?
  • Create a Hudson job for iiop-folb-dev-test (Harshad)
  • Needs to report results in a JUnit XML report (Ken is fixing in iiop-folb-dev-test)
  • Need to introduce a means of customizing run.sh, probably something like ~/.iiop-folb-dev-test
  • Create Hudson jobs for CORBA SQE tests (Harshad)
  • CORBA SQE tests are available in the locked project corba-sqe-tests (I just added Harshad as a member).
  • Create Hudson job(s) for performance testing
  • First one is StandardTest (in ORB regression tests)
  • Want both local and remote testing
  • Want to run it under Japex to gather performance info
  • Test is already complete and works, just need to automate under Hudson
  • Others?
  • Maribor is a candidate (currently in the perf team's reference workload)
  • Maribor needs quite a bit of work
  • Create Hudson jobs for GF integration test (Harshad)
  • This part is underway


 Comments   
Comment by Harshad Vilekar [ 08/Dec/11 ]

Following hudson jobs are deployed on hudson-sca.us.oracle.com:

  • Corba Master Workspace + GlassFish 3.1.2 Workspace
    corba-build-test-orb
    corba-orb-iiop-folb-devtest
  • Corba Staging Workspace + GlassFish Trunk Workspace
    corba-staging-build-test-orb
    corba-staging-iiop-folb-devtest
  • Corba/GlassFish Pre Integration Test
    corba-glassfish-preint-test




[GLASSFISH-17310] Remote session bean call with entity - data problem/corba stream corruption when using IP address Created: 16/Sep/11  Updated: 25/Nov/11

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: sarnoth Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

When a session bean is called remotely and either its parameters or return value contain an entity bean there is a data transmission problem that seems to be caused by corba stream corruption when the InitialContext was created using an IP address.

The problem manifests as follows:

  • If a single entity is passed in or out of the method it is received with all values set to null even though they were filled in on the sending side.
  • If a List of entities is passed in or out an exception is generated from within the corba stack indicating stream corruption. The exact exception varies depending on the makeup of the entity.

The problem can be reproduced in two ways:

  • From a simple standalone program construct an InitialContext with a properties object where an IP address is specified for org.omg.CORBA.ORBInitialHost. Call a method on a remote session bean interface passing in a new instance of an entity bean or receiving one as a return value.
  • Deploy two ears to the same cluster. One ear should contain a session bean with remote interface and entity bean. The other ear should contain a component that calls the session bean in the first ear via an injected reference (@EJB MyTestSessionRemote foo and passes in an entity or receives one as a return value. This is the real show stopper since we do not have control over the host name used in this case so we have no way to make sure that it is not an IP address. This always fails and is preventing us from being able to migrate to glassfish 3.1.1.

Additional notes:

  • This happens only for entities, not for other objects or lists of object. The state of the entity does not matter (new, managed, detached).
  • The problem happens only when an IPv4 IP address is used. It does not happen when a host name is used and it does not happen when an IPv6 address is used.
  • A tcpdump on the side of an external client passing in an entity through a remote interface shows that the data is being sent across the wire, so it would seem to be a problem on the deserialization side.
  • The problem happens if IP addresses are used with the "com.sun.appserv.iiop.endpoints" property as well as if an IP address is used with the "org.omg.CORBA.ORBInitialHost" property.

Simple standalone client example that demonstrates the problem:
public static void main(String[] args) throws NamingException {
Properties contextEnv = new Properties();
// contextEnv.setProperty("org.omg.CORBA.ORBInitialHost", "testhostname"); // problem does not happen
contextEnv.setProperty("org.omg.CORBA.ORBInitialHost", "x.y.z.w"); // problem happens
// contextEnv.setProperty("org.omg.CORBA.ORBInitialHost", "[::FFFF:x.y.z.w]"); // problem does not happen
contextEnv.setProperty("org.omg.CORBA.ORBInitialPort", "11037");
InitialContext ctx = new InitialContext(contextEnv);
TestSessionRemote t = (TestSessionRemote)ctx.lookup(TestSessionRemote.class.getName());
TestEntity e = new TestEntity(1, "test1", 1L); // int, String, Long
t.test(e); // when the problem happens the received values are 0, null, null
}

Let me know if there is any more information that I can provide. This is a critical issue for us.



 Comments   
Comment by Cheng Fang [ 16/Sep/11 ]

assign to orb for initial evaluation.

Are these entities serializable, or employ any custom serialization?

Comment by sarnoth [ 16/Sep/11 ]

The entities implement Serializable and have a serialVersionUID. There is no custom serialization and all the column types are simple (int, String, Long). Below is a test entity that I used to reproduce the problem.

@Entity
@Table(schema = "svrmgr", name = "site_code")
public class TestEntity implements Serializable {
    private static final long serialVersionUID = 1L;
    
    @Id
    @Column(name = "site_id", nullable = false)
    private int id;
    
    @Column(name = "site_name", nullable = false)
    private String name;
    
    @Column(name = "initial_duration_seconds", nullable = false)
    private Long value;
    
    public TestEntity() {
    }

    public TestEntity(int id, String name, Long value) {
        this.id = id;
        this.name = name;
        this.value = value;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Long getValue() {
        return value;
    }

    public void setValue(Long value) {
        this.value = value;
    }
}
Comment by Cheng Fang [ 18/Nov/11 ]

so the key points here are IPv4 IP address and the de-serialization of entity objects. Have you tried configuring or disabling eclipselink weaving? Not sure if that's related, just some wild guess.

Comment by sarnoth [ 21/Nov/11 ]

I tried disabling weaving and that did work around the problem.

Comment by thomas.giger [ 25/Nov/11 ]

We see exactly the same problem (except for the fact that the hostname does not work either)
In our environment, disabling weaving is not an option..? Are there any other work-arounds known?





[GLASSFISH-17281] javax.ejb.AsyncResult in Remote interfaces with DTOs generates ClassCastException on client Created: 08/Sep/11  Updated: 23/Nov/12

Status: In Progress
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: vins4java Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista SP2
JDK 1.6.0_26


Attachments: Zip Archive AsyncTestCase-src.zip     File module-a-ear.ear     File module-b-ear.ear    
Tags: 3_1_2-exclude, asynchronous, ejb31

 Description   

Scenario:

  • 2 ear apps say A and B (module-a-ear and module-b-ear)
  • each ear has contains an ejb-jar (module-a-ejb and module-b-ejb)
  • A's ejb exposes remote interface with an @Asyncronous method
  • the asyncronous method returns a serializable DTO (ADto)
  • both A and B have the same copy of A's ejbClient in their ear's root (module-a-ejbClient.jar)

when a method of B calls a remote asynch method on A, the call is perfomed but when Future<ADto> is done, on module-b-ejb side a ClassCastException is thrown when invoking:
ADto wrappedDto = futureDto.get();

EJB 3.1 specs don't make dinstinction about local or remote interface for @Asynchrouse annotation.They also don't put any limitation in Future<V>, so Data Transfer Objects (serializable) must be supported, right?

In order to have a very simple test case (didn't want to create JEE appclient..) I've annotated module-b-ejb as WebService so that you can call module-b-ejb method via glassfish admin gui webservice tester. You can find a stacktrace in the attached zip file. I also provided the 2 deployable ear files.

IMHO:
Debugging on client side (using eclipse debugger) I had a look at classloader of the ADto instance received from A: it's the A's classloader, not B's! It's strange because I tried also to change method in the "old traditional" synch fashion( public ADto doAsync() ) and on client side the returning ADto correclty comes from A's classloader. Does this help?



 Comments   
Comment by vins4java [ 14/Oct/11 ]

any update on this issue?

Comment by Cheng Fang [ 14/Oct/11 ]

I was able to reproduce it on trunk build. Stack trace is the same as in your attachment(except slightly different line numbers):

        at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5219)
        at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5117)
        at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4905)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:207)
        at $Proxy234.testIt(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)
        at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
        at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
        at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
        at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:212)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:162)
        at org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:116)
        at org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
        at org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:198)
        at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:129)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.doFilter(ServletHandler.java:985)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.invokeFilterChain(ServletHandler.java:928)
        at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:382)
        at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:335)
        at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:161)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:286)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:223)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:155)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:134)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:827)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:103)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:111)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:131)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
        at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassCastException: module.a.ejb.ADto cannot be cast to module.a.ejb.ADto
        at module.b.ejb.BBean.testIt(BBean.java:36)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5392)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:624)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:576)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:851)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:361)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5364)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5352)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:195)
        ... 60 more
Comment by Cheng Fang [ 18/Oct/11 ]

If you do not call future.isDone() on the client side, I suspect it will work.

Comment by vins4java [ 18/Oct/11 ]

unfortunately your suspect seems to be wrong: I get the same error even if I comment isDone() call on client ejb.
I've tested this modification on Glassfish 3.1.1-build12 ( on ubuntu with java-6-sun-1.6.0.26 ).
Did you try it with trunk version (3.2)?

Comment by Cheng Fang [ 19/Oct/11 ]

Looks like the payload didn't go thru proper marshalling and unmarshalling when both sides are colocated. It could also be some caching problem.

Comment by vins4java [ 25/Oct/11 ]

So you tried deploying each ear in two different JVMs (on the same physical machine or two different ones) and it worked, or you are supposing so? let me know if there's a way for me to help you to solve this problem. We are going to rely on this feature in short/med term...

Comment by Cheng Fang [ 25/Oct/11 ]

If the two modules are deployed into separate JVM, either same host or different hosts, that should work.
There is total separation of classloaders and so shouldn't be any CCE. What I found now is the DAO instance
on the ejb server side is different from the DAO instance on the client side, which means the serialization and
deserialization did happen. But the wrong classloader (the server side classloader) was used to reconstruct
the DAO on the client side. The client side application classloader should've been used for that.

Another complication is it is not the Java serialization protocol that's been used here. I'm trying to find out
how classloader is picked to copy objects by GlassFish corba and its related modules (see
glassfish.home/modules/glassfish-corba-orb.jar, pfl*.jar).

Again I think this issue only happens with all of the following:
remote async ejb method invocations;
both client and server modules are colocated in the same JVM;
some application class (e.g., business interface classes) are duplicated in both client and server modules

If you package client module and ejb module inside the same EAR file, and extract all shared classes into EAR/lib/xxx.jar,
without duplicating them in client and ejb modules, that should help avoid this CCE. I just tried it and worked.

Comment by Cheng Fang [ 04/Nov/11 ]

In org/glassfish/pfl/dynamic/copyobject/impl/ClassCopierOrdinaryImpl (in modules/pfl-dynamic.jar)
obj.getClass() is called to get the Class, which is then used to create a class copier, which in turn creates the constructor. It is hence associated with the class loader of the source object, not the target.

This part of the code is executed to copy all fields of a source object.

After changing to use thread context class loader in instead of
obj.getClass(), it worked without CCE. There could be other places the kind of changes are also necessary. Also not clear about the full implication or side effects.

Comment by Cheng Fang [ 04/Nov/11 ]

re-assign to orb team for further evaluation.

Comment by Harshad Vilekar [ 15/Dec/11 ]

Cheng and I exchanged email on this - and decided to target this issue post 3.1.2

Comment by juergenschmied [ 23/Nov/12 ]

I get this problem after upgrading from 3.1.2 to 3.1.2.2. A application that was working before is now broken with this error. Would it help do use a Future<ByteArrayOutputStream> an do serialization/deserialization by myself? It looks like this bug does not affect build-in classes.

Thanks!





[GLASSFISH-16973] Unable to deploy EJB application to second embedded glassfish instance. Created: 06/Jul/11  Updated: 14/Feb/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1, 4.0
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Bhavanishankar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Attachments: Text File console.log.txt     Java Source File Test.java    
Tags: 3_1_2-exclude

 Description   

This is a case where :

1. I create a embedded glassfish instance, start it, deploy a ejb app, and stop/dispose the instance. Note that the application is not undeployed prior to the stop (the case is slightly different from GLASSFISH-16965)

2. I create a second embedded glassfish instance, start it, deploy the same app as in (1), stop/dispose the instance.

But the deployment of ejb app to the second instance fails with

 "java.lang.RuntimeException: Error while binding JNDI name org.glassfish.tests.embedded.ejb.remoteejb.RemoteEJBInf__3_x_Internal_RemoteBusinessHome__ for EJB : RemoteEJB". 

Steps to reproduce:

1. Download the attached Test.java
2. Download remoteejb.jar from GLASSFISH-16546
3. Set S1AS_HOME to point to your 3.1.1 installation
4. javac -g -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar Test.java
5. java -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar: Test; // I have attached my console output.

I happen to exercise this case because of the workaround mentioned in GLASSFISH-16916 by Harshad. Unfortunately the workaround does not work because of this issue.



 Comments   
Comment by marina vatkina [ 06/Jul/11 ]

One more area not designed for a restart in the same VM...

Comment by marina vatkina [ 06/Jul/11 ]

Note that embeddable EJB Container works fine because it completely disposes GFRuntime.

Comment by Cheng Fang [ 10/Jul/11 ]

There was an error when calling unpublishCosNamingObject for EJB internal home jndi name during shutdown. So these 2 entries remain in TransientContext bindings. My proposal is to ignore this orb failure and continue to unbind them from TransientContext.

The stacktrace:

java.lang.NullPointerException
	at com.sun.corba.ee.impl.orb.ORBImpl.getInvocationInfo(ORBImpl.java:1911)
	at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.getClientRequestDispatcher(CorbaClientDelegateImpl.java:308)
	at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:290)
	at org.omg.CORBA.portable.ObjectImpl._releaseReply(ObjectImpl.java:474)
	at org.omg.CosNaming._NamingContextStub.unbind(_NamingContextStub.java:301)
	at com.sun.jndi.cosnaming.CNCtx.callUnbind(CNCtx.java:712)
	at com.sun.jndi.cosnaming.CNCtx.unbind(CNCtx.java:768)
	at com.sun.jndi.cosnaming.CNCtx.unbind(CNCtx.java:752)
	at javax.naming.InitialContext.unbind(InitialContext.java:416)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishCosNamingObject(GlassfishNamingManagerImpl.java:260)
	at com.sun.ejb.containers.BaseContainer$JndiInfo.unpublish(BaseContainer.java:5618)
	at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4298)
	at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4237)
	at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:307)
	at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
	at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
	at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1971)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:454)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:422)
	at com.sun.hk2.component.AbstractCreatorInhabitantImpl.dispose(AbstractCreatorInhabitantImpl.java:83)
	at com.sun.hk2.component.SingletonInhabitant.release(SingletonInhabitant.java:81)
	at com.sun.hk2.component.EventPublishingInhabitant.release(EventPublishingInhabitant.java:108)
	at com.sun.hk2.component.LazyInhabitant.release(LazyInhabitant.java:133)
	at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:425)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
	at Test.main(Test.java:22)
Comment by Cheng Fang [ 10/Jul/11 ]

Tried this following fix in GlassFishNamingManagerImpl, the attached the test passed:

Index: src/main/java/com/sun/enterprise/naming/impl/GlassfishNamingManagerImpl.java
===================================================================
--- src/main/java/com/sun/enterprise/naming/impl/GlassfishNamingManagerImpl.java	(revision 47909)
+++ src/main/java/com/sun/enterprise/naming/impl/GlassfishNamingManagerImpl.java	(working copy)
@@ -258,7 +258,7 @@
 
         try {
             getCosContext().unbind(name);
-        } catch(NamingException cne) {
+        } catch(Exception cne) {
            _logger.log(Level.WARNING, "Error during CosNaming.unbind for " + name); 
         }
Comment by Cheng Fang [ 12/Jul/11 ]

Assign to orb team to evaluate the ORB NPE.

Comment by Harshad Vilekar [ 14/Feb/13 ]

Defer the restart requirement. There are missing defensive null value checks at some places in the ORB code.





[GLASSFISH-18791] EJB-Client hangs after changing client's system clock Created: 08/Jun/12  Updated: 22/Nov/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: olafj Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server side: Windows 7, Java 1.6.0_27-b07
Client side: Mac OSX, Java 1.7.0._04


Attachments: Text File dump.txt     Zip Archive TestEA-Client.zip     Zip Archive TestEA-ejb.zip    

 Description   

EJB-Client hangs after changing client's system clock:
We have deployed a simple ejb stateless bean with a simple method that just returns a static string.
On the client side we create an initial context, do a lookup for a remote facade of our stateless session bean and call the simple method.
Everything works fine until we change the system clock of the client machine to a time in future.
The first ejb-call after time change hangs until we get an timeout after 30 minutes.



 Comments   
Comment by olafj [ 11/Jun/12 ]

Netbeans projects (Source files)

Comment by olafj [ 11/Jun/12 ]

Same scenario using JBoss AS 6 works fine.

Comment by olafj [ 11/Jun/12 ]

Attached dump created via jstack for freezed java process on windows. Dump was created directly after first call after change of client time.

Comment by olafj [ 19/Jun/12 ]

Is there any progress on this issue? Are you need more information? Can i help to clearify open questions?

Comment by Harshad Vilekar [ 21/Jun/12 ]

What version/build of GlassFish is used on the client machine ? The attached thread dump doesn't match the ORB 3.1.2 source code.

Comment by olafj [ 21/Jun/12 ]

I was able to reproduce the problem with glassfish 3.0.1 / 3.1.2 / 4.X server-side and with corresponding gf-client-libs on the client machine.
It is a big problem for us in production mode due to automatic time correction in all client machines. So every time a client machine has in incorrect time a scheduled tasks in local network will correct the time, mostly from the past to current time, and after that gf-client hangs.

Comment by olafj [ 03/Jul/12 ]

Any new ideas? How can i help?

Comment by olafj [ 11/Jul/12 ]

Another customer told us that their installation has run into the same problem. Do you know any workaround?

Comment by boernd [ 22/Nov/13 ]

Hi,

did you find a workaround for this issue? We also run in a very similiar problem where threads get stuck in TIMED_WAITING in the ResponseWaitingRoomImpl.waitForResponse Method (Solaris 10, JDK7 Update25 64bit).

Regards
Bernd





[GLASSFISH-18897] Remove non OSGI (exception-annotation-processor.jar) from glassfish-corba-orb of glassfish-corba bundle Created: 13/Jul/12  Updated: 16/Jul/12

Status: Open
Project: glassfish
Component/s: orb, packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: vijay_oracle Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

cp glassfish3/glassfish/config/osgi.properties glassfish3/glassfish/domains/domain1/config
set glassfish.osgi.ondemand=true
Start Glassfish server (./asadmin start-domain -v)


Attachments: Text File Error.txt    
Tags: corba, packager

 Description   

glassfish-corba artifact has a dependency on artifact id glassfish-corba-orb with group id org.glassfish.corba; being an external jar it has a dependency on exception-annotation-processor.jar which is non OSGI and has no OSGI metadata available. Because of this plain jar being packaged and available in modules directory in distribution the server fails to startup.

The JAR needs to be removed from getting packaged during the build.

Please find the Exception attached.






[GLASSFISH-18632] orb-connector brings in a lot of dependencies Created: 16/Apr/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b32_ms1
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: spo

 Description   

orb-connector is getting started at startup time and it has a lot of dependencies, so this needs to be fixed asap.






[GLASSFISH-18722] [PERF] Standalone client fails receiving 1k or longer string via IIOP (Blocking IIOP-based perf tests) Created: 13/May/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b36
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG, Sev2_Candidate, vikkumar_func

 Description   

Accessing a remote EJB to get 1k, 100k strings via a standalone client fails with error. This issue is present in 3.1.2 as well. In Solaris this happens all the time, for Linux it happens more on secure listener and sometimes on non-secure listener too.

java.rmi.MarshalException: CORBA COMM_FAILURE 1330446373 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: WARNING: 00410037: Timeout while reading data in buffer manager vmcid: OMG minor code: 37 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:258)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:211)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at weblogic.performance.benchmarks.rmi._EJBRMIBenchmarks_DynamicStub.getString(weblogic/performance/benchmarks/rmi/_EJBRMIBenchmarks_DynamicStub.java)
at weblogic.performance.benchmarks.rmi.clients.GetStringUser.op(RMIUser.java:148)
at weblogic.performance.benchmarks.rmi.clients.RMIUser.execute(RMIUser.java:70)
at weblogic.performance.utils.controller.ClientThread.run(ClientThread.java:81)
Caused by: org.omg.CORBA.COMM_FAILURE: WARNING: 00410037: Timeout while reading data in buffer manager vmcid: OMG minor code: 37 completed: No
at $Proxy28.bufferReadManagerTimeout(Unknown Source)
at com.sun.corba.ee.impl.encoding.BufferManagerReadStream.underflow(BufferManagerReadStream.java:142)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_1_1.java:113)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_octet_array(CDRInputStream_1_0.java:714)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getConvertedChars(CDRInputStream_1_0.java:2335)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.read_wstring(CDRInputStream_1_2.java:171)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1077)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:383)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:482)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:201)
... 6 more
java.rmi.MarshalException: CORBA COMM_FAILURE 1330446373 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: WARNING: 00410037: Timeout while reading data in buffer manager vmcid: OMG minor code: 37 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:258)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:211)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at weblogic.performance.benchmarks.rmi._EJBRMIBenchmarks_DynamicStub.getString(weblogic/performance/benchmarks/rmi/_EJBRMIBenchmarks_DynamicStub.java)
at weblogic.performance.benchmarks.rmi.clients.GetStringUser.op(RMIUser.java:148)
at weblogic.performance.benchmarks.rmi.clients.RMIUser.execute(RMIUser.java:70)
at weblogic.performance.utils.controller.ClientThread.run(ClientThread.java:81)
Caused by: org.omg.CORBA.COMM_FAILURE: WARNING: 00410037: Timeout while reading data in buffer manager vmcid: OMG minor code: 37 completed: No
at $Proxy28.bufferReadManagerTimeout(Unknown Source)
at com.sun.corba.ee.impl.encoding.BufferManagerReadStream.underflow(BufferManagerReadStream.java:142)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_1_1.java:113)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_octet_array(CDRInputStream_1_0.java:714)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getConvertedChars(CDRInputStream_1_0.java:2335)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.read_wstring(CDRInputStream_1_2.java:171)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1077)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:383)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:482)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:201)
... 6 more
null



 Comments   
Comment by Harshad Vilekar [ 14/May/12 ]

Could you rerun the test with the flag : "-Dcom.sun.corba.ee.ORBDebug=transport". Please set this on both the client and the GlassFish server. And include the server log and the client side output.

Also, is it possible to attach the test that duplicates the issue ? I ran a simple app that invokes a remote method that returns a string of size > 100K. The call is repeated 1000 times, but it couldn't duplicate the failure on my Solaris / Linux box.

Comment by Scott Oaks [ 04/Dec/12 ]

In May at perf team meetings, we discussed that the ORBDebug output would be too large for this test to make sense of, and that we expected the behavior might change after the summertime ORB integrations (but the latter isn't hte case; this is still an issue).

Comment by Harshad Vilekar [ 11/Feb/13 ]

Looking at the issue now. Tried the test case provided by Amit, and could duplicate the client side exception on my Linux box with the latest GF 4.0 build.





[GLASSFISH-15224] Accessing context from remote application client fails Created: 15/Dec/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b33
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: edmondo1984 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

An application client project deployed inside an EAR with custom jnlp file


Attachments: Zip Archive glassfishbug.zip     File TestEJBFromClientForJWS.ear     Zip Archive TestEJBFromClientForJWS.zip    
Tags: 3_1-exclude

 Description   

Java Web Start 1.6.0_22
Utilisation de la version JRE 1.6.0_22-b04 Java HotSpot(TM) Client VM
Répertoire d'accueil de l'utilisateur = C:\Documents and Settings\porcu
----------------------------------------------------
c: effacer la fenêtre de la console
f: finaliser les objets de la file d'attente de finalisation
g: libérer la mémoire
h: afficher ce message d'aide
m: imprimer le relevé d'utilisation de la mémoire
o: déclencher la consignation
p: recharger la configuration du proxy
q: masquer la console
r: recharger la configuration des politiques
s: vider les propriétés système et déploiement
t: vider la liste des threads
v: vider la pile des threads
0-5: fixer le niveau de traçage à <n>
----------------------------------------------------
14 déc. 2010 15:02:56 com.sun.logging.LogDomains$1 log
INFO: Cannot find javadb client jar file, derby jdbc driver will not be
available by default.
14 déc. 2010 15:02:57 com.sun.logging.LogDomains$1 log
INFO: enterprise_used_delegate_name
14 déc. 2010 15:02:58 com.sun.logging.LogDomains$1 log
ATTENTION: gf.counterpart.configdd.exists
14 déc. 2010 15:03:07
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2 invoke
SEVERE: IOP00410016: Unable to create IIOP listener on the specified
port: 10.11.12.203
org.omg.CORBA.COMM_FAILURE: SEVERE: IOP00410016: Unable to create IIOP
listener on the specified port: 10.11.12.203 vmcid: OMG minor code:
16 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.createListenerFailed(Unknown Source)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:98)
at
com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(
CorbaTransportManagerImpl.java:243)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.g
etAcceptorIterator(LegacyServerSocketManagerImpl.java:163)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.l
egacyIsLocalServerPort(LegacyServerSocketManagerImpl.java:130)
at
com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl.isLocal(IIOPProfileImpl.
java:341)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setLocalSubcon
tract(CorbaContactInfoListImpl.java:399)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setEffectiveTa
rgetIOR(CorbaContactInfoListImpl.java:232)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setTargetIOR(C
orbaContactInfoListImpl.java:212)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.<init>(CorbaCo
ntactInfoListImpl.java:176)
at
com.sun.corba.ee.spi.transport.TransportDefault$1.create(TransportDefau
lt.java:70)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.
java:803)
at
com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.<init>(BootstrapRe
solverImpl.java:83)
at
com.sun.corba.ee.spi.resolver.ResolverDefault.makeBootstrapResolver(Res
olverDefault.java:89)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.initializeNaming(ORBConfi
guratorImpl.java:363)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfigurator
Impl.java:152)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:617)
at
com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:696)
at
com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:683)
at
com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFis
hORBManager.java:580)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFish
ORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(Gl
assFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishOR
BHelper.java:120)
at
com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:
366)
at
com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(Serial
Context.java:373)
at
com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialCo
ntext.java:400)
at
com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.
java:348)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
544)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
491)
at javax.naming.InitialContext.lookup(Unknown Source)
at
gottwareremoteclient.connectors.RemoteServerConnector.getInitialDataObj
ect(RemoteServerConnector.java:79)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:278)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:264)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.BindException: Cannot assign requested address:
bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSoc
ket(IIOPSSLSocketFactory.java:293)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:91)
... 39 more
14 déc. 2010 15:03:07
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2 invoke
WARNING: IOP01210027: Error in running ORB configurator
org.omg.CORBA.BAD_OPERATION: WARNING: IOP01210027: Error in running ORB
configurator vmcid: OMG minor code: 27 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.orbConfiguratorError(Unknown Source)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:619)
at
com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:696)
at
com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:683)
at
com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFis
hORBManager.java:580)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFish
ORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(Gl
assFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishOR
BHelper.java:120)
at
com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:
366)
at
com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(Serial
Context.java:373)
at
com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialCo
ntext.java:400)
at
com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.
java:348)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
544)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
491)
at javax.naming.InitialContext.lookup(Unknown Source)
at
gottwareremoteclient.connectors.RemoteServerConnector.getInitialDataObj
ect(RemoteServerConnector.java:79)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:278)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:264)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.omg.CORBA.COMM_FAILURE: SEVERE: IOP00410016: Unable to
create IIOP listener on the specified port: 10.11.12.203 vmcid: OMG
minor code: 16 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.createListenerFailed(Unknown Source)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:98)
at
com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(
CorbaTransportManagerImpl.java:243)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.g
etAcceptorIterator(LegacyServerSocketManagerImpl.java:163)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.l
egacyIsLocalServerPort(LegacyServerSocketManagerImpl.java:130)
at
com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl.isLocal(IIOPProfileImpl.
java:341)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setLocalSubcon
tract(CorbaContactInfoListImpl.java:399)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setEffectiveTa
rgetIOR(CorbaContactInfoListImpl.java:232)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setTargetIOR(C
orbaContactInfoListImpl.java:212)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.<init>(CorbaCo
ntactInfoListImpl.java:176)
at
com.sun.corba.ee.spi.transport.TransportDefault$1.create(TransportDefau
lt.java:70)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.
java:803)
at
com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.<init>(BootstrapRe
solverImpl.java:83)
at
com.sun.corba.ee.spi.resolver.ResolverDefault.makeBootstrapResolver(Res
olverDefault.java:89)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.initializeNaming(ORBConfi
guratorImpl.java:363)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfigurator
Impl.java:152)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:617)
... 24 more
Caused by: java.net.BindException: Cannot assign requested address:
bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSoc
ket(IIOPSSLSocketFactory.java:293)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:91)
... 39 more
14 déc. 2010 15:03:07 com.sun.logging.LogDomains$1 log
SEVERE: enterprise_util.excep_in_createorb
org.omg.CORBA.BAD_OPERATION: WARNING: IOP01210027: Error in running ORB
configurator vmcid: OMG minor code: 27 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.orbConfiguratorError(Unknown Source)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:619)
at
com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:696)
at
com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:683)
at
com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFis
hORBManager.java:580)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFish
ORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(Gl
assFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishOR
BHelper.java:120)
at
com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:
366)
at
com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(Serial
Context.java:373)
at
com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialCo
ntext.java:400)
at
com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.
java:348)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
544)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
491)
at javax.naming.InitialContext.lookup(Unknown Source)
at
gottwareremoteclient.connectors.RemoteServerConnector.getInitialDataObj
ect(RemoteServerConnector.java:79)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:278)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:264)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.omg.CORBA.COMM_FAILURE: SEVERE: IOP00410016: Unable to
create IIOP listener on the specified port: 10.11.12.203 vmcid: OMG
minor code: 16 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.createListenerFailed(Unknown Source)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:98)
at
com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(
CorbaTransportManagerImpl.java:243)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.g
etAcceptorIterator(LegacyServerSocketManagerImpl.java:163)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.l
egacyIsLocalServerPort(LegacyServerSocketManagerImpl.java:130)
at
com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl.isLocal(IIOPProfileImpl.
java:341)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setLocalSubcon
tract(CorbaContactInfoListImpl.java:399)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setEffectiveTa
rgetIOR(CorbaContactInfoListImpl.java:232)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setTargetIOR(C
orbaContactInfoListImpl.java:212)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.<init>(CorbaCo
ntactInfoListImpl.java:176)
at
com.sun.corba.ee.spi.transport.TransportDefault$1.create(TransportDefau
lt.java:70)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.
java:803)
at
com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.<init>(BootstrapRe
solverImpl.java:83)
at
com.sun.corba.ee.spi.resolver.ResolverDefault.makeBootstrapResolver(Res
olverDefault.java:89)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.initializeNaming(ORBConfi
guratorImpl.java:363)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfigurator
Impl.java:152)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:617)
... 24 more
Caused by: java.net.BindException: Cannot assign requested address:
bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSoc
ket(IIOPSSLSocketFactory.java:293)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:91)
... 39 more
java.lang.RuntimeException: Orb initialization erorr
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishOR
BHelper.java:148)
at
com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:
366)
at
com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(Serial
Context.java:373)
at
com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialCo
ntext.java:400)
at
com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.
java:348)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
544)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:
491)
at javax.naming.InitialContext.lookup(Unknown Source)
at
gottwareremoteclient.connectors.RemoteServerConnector.getInitialDataObj
ect(RemoteServerConnector.java:79)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:278)
at
gottwareremoteclient.GottwareRemoteClientStartupView$Task.doInBackgroun
d(GottwareRemoteClientStartupView.java:264)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: org.omg.CORBA.BAD_OPERATION:
WARNING: IOP01210027: Error in running ORB configurator vmcid: OMG
minor code: 27 completed: No
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFis
hORBManager.java:621)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFish
ORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(Gl
assFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishOR
BHelper.java:120)
... 17 more
Caused by: org.omg.CORBA.BAD_OPERATION: WARNING: IOP01210027: Error in
running ORB configurator vmcid: OMG minor code: 27 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.orbConfiguratorError(Unknown Source)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:619)
at
com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:696)
at
com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:683)
at
com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFis
hORBManager.java:580)
... 20 more
Caused by: org.omg.CORBA.COMM_FAILURE: SEVERE: IOP00410016: Unable to
create IIOP listener on the specified port: 10.11.12.203 vmcid: OMG
minor code: 16 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:248)
at
com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(C
orbaExtension.java:95)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(W
rapperGenerator.java:422)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$300(WrapperG
enerator.java:107)
at
com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGen
erator.java:531)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invok
e(CompositeInvocationHandlerImpl.java:99)
at $Proxy35.createListenerFailed(Unknown Source)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:98)
at
com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(
CorbaTransportManagerImpl.java:243)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.g
etAcceptorIterator(LegacyServerSocketManagerImpl.java:163)
at
com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.l
egacyIsLocalServerPort(LegacyServerSocketManagerImpl.java:130)
at
com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl.isLocal(IIOPProfileImpl.
java:341)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setLocalSubcon
tract(CorbaContactInfoListImpl.java:399)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setEffectiveTa
rgetIOR(CorbaContactInfoListImpl.java:232)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setTargetIOR(C
orbaContactInfoListImpl.java:212)
at
com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.<init>(CorbaCo
ntactInfoListImpl.java:176)
at
com.sun.corba.ee.spi.transport.TransportDefault$1.create(TransportDefau
lt.java:70)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.
java:803)
at
com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.<init>(BootstrapRe
solverImpl.java:83)
at
com.sun.corba.ee.spi.resolver.ResolverDefault.makeBootstrapResolver(Res
olverDefault.java:89)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.initializeNaming(ORBConfi
guratorImpl.java:363)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfigurator
Impl.java:152)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:617)
... 24 more
Caused by: java.net.BindException: Cannot assign requested address:
bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSoc
ket(IIOPSSLSocketFactory.java:293)
at
com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(
SocketOrChannelAcceptorImpl.java:91)
... 39 more

Actually it looks like Glassfish is using my computer ip (10.11.12.203)
as a port to create the IIOP listener...



 Comments   
Comment by edmondo1984 [ 15/Dec/10 ]

Either you initialize the context this way
InitialContext ctx = new InitialContext();
or passing a properties file to the constructor, we have the same issue...
Best Regards
Edmondo Porcu

Comment by Tim Quinn [ 16/Dec/10 ]

I've attached two files: an EAR containing an EJB module and an app client module which reproduces this error and a zip containing the NetBeans project for the example.

Deploy the EAR using:

asadmin deploy TestEJBFromClientForJWS.ear

For me, launching the client using Java Web Start from the same system works. Use

javaws "http://localhost:8080/TestEJBFromClientForJWS/TestEJBFromClientForJWS-app-client"

Be patient! It will take Java Web Start a moment to download the files needed. You will be prompted whether to let the application continue; you should. (This is because the downloaded JARs are signed with a self-signed cert.)

After the download finishes there might be a moment's delay but then you should see a small GUI window appear. If you get this far, then naming and the ORB have successfully contacted the server and injected some annotated fields. If you click the Update button then values appear in the text fields. If that happens then an explicit look-up of the EJB has succeeded, but that's not the main issue- at least not yet.

Now, go to another system. Launch the client again from there, using the same javaws command as above except using the correct host name for where you are running the DAS. When I tried this I got errors as Edmondo has posted during the attempt to inject the annotated fields.

Comment by Tim Quinn [ 16/Dec/10 ]

You can reproduce the problem without using Java Web Start.

The easiest way is this:

1. Enable secure admin (so you can do things from the other system):
asadmin start-domain
asadmin enable-secure-admin
asadmin stop-domain
asadmin start-domain

Accept the self-signed cert when you are asked.

2. On the other non-DAS system:

asadmin deploy --retrieve loc TestEJBFromClientForJWS.ear

This creates a directory structure at "loc".

3. Try to launch the client using

appclient -targetserver dasHost:3700 -jar loc/TestEJBFromClientForJWSClient.jar

If you want to debug, it's easy. Just add the debug config to the appclient command line:

appclient -agentlib:jdwp=transport=dt_socket,address=8118,server=y,suspend=y -targetserver dasHost:3700 -jar loc/TestEJBFromClientForJWSClient.jar

Comment by Tim Quinn [ 16/Dec/10 ]

I have edited the summary. The failure does not depend on launching using Java Web Start.

Comment by Ken Cavanaugh [ 20/Dec/10 ]

Assigning to Harold for initial evaluation.

Can this fix be postponed to GF 3.2?

Comment by edmondo1984 [ 21/Dec/10 ]

For me it is really blocking, I will have to move back to Glassfish 3.0.1 for my app to work..

Comment by Ken Cavanaugh [ 21/Dec/10 ]

I understand this is blocking you, but it came in very late in the GF 3.1 relelase cycle.
I'm not sure whether we can get to this issue in this release, given the lateness of the date
and the number of other ORB issues we are working on.

Comment by Ken Cavanaugh [ 21/Dec/10 ]

It's too late in the 3.1 release cycle to fix this: moving to 3.2.

Comment by super_glassfish [ 22/Dec/10 ]

You may wish to check with your support representative if you need this fixed sooner than the 3.2 release cycle.

Comment by Ken Cavanaugh [ 04/Feb/11 ]

This issue may be a duplicate of 15786, which I just fixed today (2/4/11).
The reporter may wish to check this on a build from a later date and see if it
is fixed.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-12086] Remote IIOP lookup with CSiv2 (SSL) not working Created: 01/Jun/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: gfuser9999 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File gfv3orbclient.war     Java Archive File gfv3orbremote.jar    
Issuezilla Id: 12,086
Tags: 3_1-exclude

 Description   

Config: GFv3/GFv3-b20
Problem:

  • Say one create two glassfish v3 (3.0.1) instances A and B.
  • Deploy a remote EJB with the following ior-security in sun-ejb-jar.xml
    in instance B
    <ior-security-config>
    <transport-config>
    <integrity>required</integrity>
    <confidentiality>required</confidentiality>
    ....
    </ior-security-config>
  • Now deploy a web orb client pn the other instance A
  • To avoid any SSL trust store, say we copy
    from A's config/*jks to B's config (so they all use
    the same keystore/truststore)
  • Now when you try to lookup this remote IOR, it will fail with

Caused by: javax.naming.NamingException: ejb ref resolution error for remote
business interfaceorg.test.ejb.GFRemote [Root exception is
org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: OMG minor code: 2 completed: No]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:430)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:70)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at
com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:472)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:437)
... 33 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: OMG minor code: 2
completed: No
at
com.sun.corba.ee.impl.logging.OMGSystemException.noObjectAdaptor(OMGSystemException.java:3457)
at
com.sun.corba.ee.impl.logging.OMGSystemException.noObjectAdaptor(OMGSystemException.java:3475)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:222)
at
com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:109)
at
com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:90)
at
com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:72)
at
com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:218)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:543)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:205)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)
at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)
at
com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:418)
... 37 more
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent:
IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1057)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:218)
... 51 more

==========
BASE cases
==========
1. Same testcase works on GFv2 (with and w/o the IOR-security config)
2. Removing the ior-security in the sun-ejb-jar.xml
and it works on GFv3.
3. Only when there is ior-security with the above settings with GFv3
will fail.

TESTCASE
========
1. Create 2 instances
2. Make both of these instance share/use the same JKS
3. Deploy gfv3orbclient.war to instance A
4. Deploy gfv3remote.jar to instance B
5. Access on Instance A http://<instanceA>/gfv3client/
Set the appropriate values for the instance B (ORB port)



 Comments   
Comment by gfuser9999 [ 01/Jun/10 ]

Created an attachment (id=4395)
gfv3orbclient.war

Comment by gfuser9999 [ 01/Jun/10 ]

Created an attachment (id=4396)
gfv3orbremote.jar

Comment by Ken Cavanaugh [ 06/Oct/10 ]

Will investigate for GF 3.1.

Comment by Ken Cavanaugh [ 17/Nov/10 ]

No time for GF 3.1: moving to 3.2.

Comment by Nazrul [ 18/Nov/10 ]

Excluding from 3.1 query

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-13162] hanging RMI client & unfulfilled request with COMM_FAILURE Created: 27/Aug/10  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: petraleomue Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ClientOrbTransportLog.txt     Text File ORBErrorClient.log     Text File server.log    
Issuezilla Id: 13,162
Tags: 3_1-exclude

 Description   

We are using version v3 (build 74.2) and encounter a verry strange but
reproducible behavior. Our fat clients does something like:

InitialContext
lookup first service
call first service
lookup second service
call second service

All goes well until the client reaches the last step. There it stays until
ORBWaitForResponseTimeout is reached (even if this lasts for a whole night).
The second service is never called but some RuntimeException is thrown at the
server:

[#|2010-08-27T09:55:41.233+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|org.omg.CORBA.COMM_FAILURE:
vmcid: SUN minor code: 201 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:3431)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:3452)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:256)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:269)
...
Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection
timed out
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:239)
... 51 more
Caused by: java.net.ConnectException: Connection timed out
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:106)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:325)
... 52 more

(Details see down below)

I've enabled transport logging for the client site and it states for the last call:

ClientGroupManager(main): .getSocketInfo->:
ClientGroupManager(main): .getSocketInfo: handling non SSL socketInfo
ClientGroupManager(main): .getSocketInfo: address from: primary;
type/address/port: IIOP_CLEAR_TEXT/hvbm0jt3g30001/3701
ClientGroupManager(main): .getSocketInfo<-:
CorbaContactInfoListImpl(main): .createContactInfoList: first time for:
com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl@a71497ee list:
[SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]]
CorbaContactInfoListIteratorImpl(main): .hasNext->:
ClientGroupManager(main): .hasNext->:
key : SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
previous: null
list:
1 SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
ClientGroupManager(main): .hasNext<-: true
CorbaContactInfoListIteratorImpl(main): .hasNext<-: true
ClientGroupManager(main): .next->:
key : SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
previous: null
list:
1 SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
ClientGroupManager(main): .next: map:
key : SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
value: SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]

ClientGroupManager(main): .next: primary mapped to:
SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
ClientGroupManager(main): .next<-: mapped:
SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701]
CorbaOutboundConnectionCacheImpl(main): .get:
SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT hvbm0jt3g30001 3701] -1223306761
CorbaOutboundConnectionCacheImpl(main): .stats: 2/total 0/busy 2/idle (240/5)
ByteBufferWithInfo(main): constructor (ORB, BufferManagerWrite) - got ByteBuffer
id (15179443) from ByteBufferPool.
CorbaResponseWaitingRoomImpl(main): .registerWaiter: op/execute id/10
CorbaOutboundConnectionCacheImpl(main): .reclaim->: 2 (240/5)
CorbaOutboundConnectionCacheImpl(main): .reclaim<-: 2
ClientGroupManager(main): .send_request->: execute
ClientGroupManager(main): .send_request: execute: no membership label
ClientGroupManager(main): .send_request<-: execute
CDROutputObject(main): .writeTo: SocketOrChannelConnectionImpl[
java.nio.channels.SocketChannel[connected local=/10.50.196.60:59468
remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED true true]
CorbaResponseWaitingRoomImpl(main): .waitForResponse->: op/execute id/10
CorbaResponseWaitingRoomImpl(main): .waitForResponse: waiting: op/execute id/10
TemporarySelectorStateOpen(p: default-threadpool; w: 1): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@18bd37a, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 1): select()->: selector:
sun.nio.ch.WindowsSelectorImpl@18bd37a, timeout: 2400
TemporarySelectorStateOpen(p: default-threadpool; w: 2): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@ecfaea, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 2): select()->: selector:
sun.nio.ch.WindowsSelectorImpl@ecfaea, timeout: 2400
TemporarySelectorStateOpen(p: default-threadpool; w: 1): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@18bd37a, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 1): select()->: selector:
sun.nio.ch.WindowsSelectorImpl@18bd37a, timeout: 2880
TemporarySelectorStateOpen(p: default-threadpool; w: 2): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@ecfaea, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 2): select()->: selector:
sun.nio.ch.WindowsSelectorImpl@ecfaea, timeout: 2880
TemporarySelectorStateOpen(p: default-threadpool; w: 1): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@18bd37a, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 1):
cancelKeyAndFlushSelector()->: selector: sun.nio.ch.WindowsSelectorImpl@18bd37a
TemporarySelectorStateOpen(p: default-threadpool; w: 1):
cancelKeyAndFlushSelector(): cancel key: sun.nio.ch.SelectionKeyImpl@14f79cb
TemporarySelectorStateOpen(p: default-threadpool; w: 1):
cancelKeyAndFlushSelector()<-: cancelled and flushed
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1): .blockingRead:
byteBuffer=java.nio.HeapByteBuffer[pos=546 lim=64000 cap=64000]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1): .blockingRead<-:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59465 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1):
.doOptimizedReadStrategy: read event handling done,
byteBuffer=java.nio.HeapByteBuffer[pos=546 lim=64000 cap=64000]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1):
.resumeSelectOnMainSelector:->
SelectorImpl(p: default-threadpool; w: 1): .registerInterestOps:->
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59465 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SelectorImpl(p: default-threadpool; w: 1): .registerInterestOps:<-
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1):
.resumeSelectOnMainSelector:<-
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1):
.doOptimizedReadStrategy<-: SocketOrChannelConnectionImpl[
java.nio.channels.SocketChannel[connected local=/10.50.196.60:59465
remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED true true]
SelectorImpl(SelectorThread): .enableInterestOps:->
SocketOrChannelConnectionImpl(p: default-threadpool; w: 1): .doWork<-:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59465 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SelectorImpl(SelectorThread): .enableInterestOps:
com.sun.corba.ee.impl.transport.SelectorImpl$SelectionKeyAndOp@14021a9
SelectorImpl(SelectorThread): .enableInterestOps:<-
TemporarySelectorStateOpen(p: default-threadpool; w: 2): select()<-: selector:
sun.nio.ch.WindowsSelectorImpl@ecfaea, number selected: 0
TemporarySelectorStateOpen(p: default-threadpool; w: 2):
cancelKeyAndFlushSelector()->: selector: sun.nio.ch.WindowsSelectorImpl@ecfaea
TemporarySelectorStateOpen(p: default-threadpool; w: 2):
cancelKeyAndFlushSelector(): cancel key: sun.nio.ch.SelectionKeyImpl@190d1e8
TemporarySelectorStateOpen(p: default-threadpool; w: 2):
cancelKeyAndFlushSelector()<-: cancelled and flushed
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2): .blockingRead:
byteBuffer=java.nio.HeapByteBuffer[pos=1845 lim=64000 cap=64000]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2): .blockingRead<-:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59468 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2):
.doOptimizedReadStrategy: read event handling done,
byteBuffer=java.nio.HeapByteBuffer[pos=1845 lim=64000 cap=64000]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2):
.resumeSelectOnMainSelector:->
SelectorImpl(p: default-threadpool; w: 2): .registerInterestOps:->
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59468 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SelectorImpl(p: default-threadpool; w: 2): .registerInterestOps:<-
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2):
.resumeSelectOnMainSelector:<-
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2):
.doOptimizedReadStrategy<-: SocketOrChannelConnectionImpl[
java.nio.channels.SocketChannel[connected local=/10.50.196.60:59468
remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED true true]
SocketOrChannelConnectionImpl(p: default-threadpool; w: 2): .doWork<-:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected
local=/10.50.196.60:59468 remote=hvbm0jt3g30001/10.58.59.119:3701] ESTABLISHED
true true]
SelectorImpl(SelectorThread): .enableInterestOps:->
SelectorImpl(SelectorThread): .enableInterestOps:
com.sun.corba.ee.impl.transport.SelectorImpl$SelectionKeyAndOp@161f888
SelectorImpl(SelectorThread): .enableInterestOps:<-

A logging for subcontract on server site starts with:
[#|2010-08-27T08:50:57.808+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleRequest->:|#]

and ends at this time with:

[#|2010-08-27T08:50:58.153+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .beginRequest->(op implementation isOneWay false
contactInfo SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT 10.50.196.60 61201])|#]

after that silence for about 4 minutes and then this, reporting a
RuntimeException that (unfortunately) isn't logged:

[#|2010-08-27T08:54:42.878+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .beginRequest<-|#]

[#|2010-08-27T08:54:42.879+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaClientDelegateImpl(p:
thread-pool-1; w: 2): .request: op/implementation: caught RuntimeException:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No|#]

[#|2010-08-27T08:54:42.880+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaClientDelegateImpl(p:
thread-pool-1; w: 2): .request: op/implementation: retry as a result of :
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No|#]

[#|2010-08-27T08:54:42.880+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.orb.ORBImpl(p:
thread-pool-1; w: 2): .createOrIncrementInvocationInfo->:|#]

[#|2010-08-27T08:54:42.881+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.orb.ORBImpl(p:
thread-pool-1; w: 2): .createOrIncrementInvocationInfo: retry|#]

[#|2010-08-27T08:54:42.881+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.orb.ORBImpl(p:
thread-pool-1; w: 2): .createOrIncrementInvocationInfo<-: entryCount: 2
com.sun.corba.ee.impl.protocol.CorbaInvocationInfo@6e2ca834|#]

[#|2010-08-27T08:54:43.137+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .beginRequest->(op implementation isOneWay false
contactInfo SocketOrChannelContactInfoImpl[IIOP_CLEAR_TEXT 10.50.196.60 61201])|#]

This is repeated another 15 times until this bug is reported although it is not
clear whether this is the original one:

[#|2010-08-27T09:55:41.225+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .beginRequest<-|#]

[#|2010-08-27T09:55:41.225+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaClientDelegateImpl(p:
thread-pool-1; w: 2): .request: op/implementation: caught RuntimeException:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No|#]

[#|2010-08-27T09:55:41.226+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaClientDelegateImpl(p:
thread-pool-1; w: 2): .request<- op/implementation|#]

[#|2010-08-27T09:55:41.226+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .endRequest->|#]

[#|2010-08-27T09:55:41.226+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.protocol.CorbaClientRequestDispatcherImpl(p:
thread-pool-1; w: 2): .endRequest<-|#]

[#|2010-08-27T09:55:41.227+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.orb.ORBImpl(p:
thread-pool-1; w: 2): .releaseOrDecrementInvocationInfo->:|#]

[#|2010-08-27T09:55:41.227+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|(ORB).impl.orb.ORBImpl(p:
thread-pool-1; w: 2): .releaseOrDecrementInvocationInfo<-: entry count: 16
com.sun.corba.ee.impl.protocol.CorbaInvocationInfo@6e2ca834|#]

[#|2010-08-27T09:55:41.227+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaServerRequestDispatcherImpl(p:
thread-pool-1; w: 2): .dispatchToServant<-: op/execute id/10:
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie@3d51a6f2
RMI:de.hvb.m0.business.mds.tacoma.rmiinterface.request.M0TacomaRequestService:0000000000000000
de.hvb.m0.business.mds.tacoma.server.request.M0TacomaRequestServiceImpl@49dbb622|#]

[#|2010-08-27T09:55:41.228+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaServerRequestDispatcherImpl(p:
thread-pool-1; w: 2): .dispatch: op/execute id/10: other exception
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No|#]

[#|2010-08-27T09:55:41.228+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleThrowableDuringServerDispatch: op/execute id/10:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No|#]

[#|2010-08-27T09:55:41.228+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createSystemExceptionResponse: op/execute id/10|#]

[#|2010-08-27T09:55:41.233+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|org.omg.CORBA.COMM_FAILURE:
vmcid: SUN minor code: 201 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:3431)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:3452)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:256)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:269)
at
com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:125)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:188)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:186)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at
com.sun.org.omg.SendingContext._CodeBaseStub.implementation(_CodeBaseStub.java:90)
at
com.sun.corba.ee.impl.encoding.CachedCodeBase.implementation(CachedCodeBase.java:116)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getClassFromString(CDRInputStream_1_0.java:2343)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1148)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:986)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:978)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:968)
at
com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:691)
at
com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:402)
at
com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:577)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:345)
at java.util.ArrayList.readObject(ArrayList.java:593)
at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1965)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1300)
at
com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:449)
at
com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:364)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:320)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1066)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1175)
at
com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:655)
at
com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2298)
at
com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2552)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1310)
at
com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:449)
at
com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:364)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:320)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1066)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1175)
at
com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:655)
at
com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:383)
at
com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readArguments(DynamicMethodMarshallerImpl.java:453)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection
timed out
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:239)
... 51 more
Caused by: java.net.ConnectException: Connection timed out
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:106)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:325)
... 52 more

#]

[#|2010-08-27T09:55:41.235+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .getServiceContextsForReply: op/execute id/10:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected ishut
local=/10.58.59.119:3701 remote=/10.50.196.60:61207] ABORT true true]|#]

[#|2010-08-27T09:55:41.245+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createResponseHelper: op/execute id/10:
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2@291faca|#]

[#|2010-08-27T09:55:41.247+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createSystemExceptionResponse: op/execute id/10|#]

[#|2010-08-27T09:55:41.248+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|org.omg.CORBA.COMM_FAILURE:
vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3484)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:1054)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:144)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:92)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:357)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:265)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:631)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:650)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.write_octet_array(CDROutputObject.java:532)
at
com.sun.corba.ee.impl.servicecontext.UnknownServiceContextImpl.write(UnknownServiceContextImpl.java:78)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeMapEntry(ServiceContextsImpl.java:380)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeServiceContextsInOrder(ServiceContextsImpl.java:329)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.write(ServiceContextsImpl.java:304)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:210)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2364)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2327)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2251)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2028)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:289)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

#]

This last exception is again written several times until:

[#|2010-08-27T09:55:41.281+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .getServiceContextsForReply: op/execute id/10:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected ishut
local=/10.58.59.119:3701 remote=/10.50.196.60:61207] ABORT true true]|#]

[#|2010-08-27T09:55:41.282+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createResponseHelper: op/execute id/10:
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2@64bcaf72|#]

[#|2010-08-27T09:55:41.282+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleThrowableDuringServerDispatch: op/execute id/10:
cannot handle: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203
completed: No|#]

[#|2010-08-27T09:55:41.282+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaServerRequestDispatcherImpl(p:
thread-pool-1; w: 2): .dispatch<-: op/execute id/10|#]

[#|2010-08-27T09:55:41.283+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleThrowableDuringServerDispatch: op/execute id/10:
java.lang.RuntimeException: handleThrowableDuringServerDispatch: cannot create
response.|#]

[#|2010-08-27T09:55:41.283+0200|WARNING|glassfishv3.0|javax.enterprise.resource.corba.ee.INITIALIZING.rpc.protocol|_ThreadID=19;_ThreadName=Thread-2;|"IOP00010202:
(UNKNOWN) Unknown user exception thrown by the server - exception:
java.lang.RuntimeException; message: handleThrowableDuringServerDispatch: cannot
create response."
org.omg.CORBA.UNKNOWN: vmcid: SUN minor code: 202 completed: Maybe
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:11015)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:2075)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2025)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1703)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.RuntimeException: handleThrowableDuringServerDispatch:
cannot create response.
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2002)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:289)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
... 7 more
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3484)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:1054)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:144)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:92)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:357)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:265)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:631)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:650)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.write_octet_array(CDROutputObject.java:532)
at
com.sun.corba.ee.impl.servicecontext.UnknownServiceContextImpl.write(UnknownServiceContextImpl.java:78)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeMapEntry(ServiceContextsImpl.java:380)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeServiceContextsInOrder(ServiceContextsImpl.java:329)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.write(ServiceContextsImpl.java:304)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:210)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2364)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2327)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2251)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2028)
... 20 more

#]

[#|2010-08-27T09:55:41.285+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createSystemExceptionResponse: op/execute id/10|#]

[#|2010-08-27T09:55:41.313+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|org.omg.CORBA.UNKNOWN:
vmcid: SUN minor code: 202 completed: Maybe
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:11015)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:2075)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2025)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1703)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.RuntimeException: handleThrowableDuringServerDispatch:
cannot create response.
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2002)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:289)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
... 7 more
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3484)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:1054)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:144)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:92)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:357)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:265)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:631)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:650)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.write_octet_array(CDROutputObject.java:532)
at
com.sun.corba.ee.impl.servicecontext.UnknownServiceContextImpl.write(UnknownServiceContextImpl.java:78)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeMapEntry(ServiceContextsImpl.java:380)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeServiceContextsInOrder(ServiceContextsImpl.java:329)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.write(ServiceContextsImpl.java:304)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:210)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2364)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2327)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2251)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2028)
... 20 more

#]

[#|2010-08-27T09:55:41.344+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .getServiceContextsForReply: op/execute id/10:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected ishut
local=/10.58.59.119:3701 remote=/10.50.196.60:61207] ABORT true true]|#]

[#|2010-08-27T09:55:41.345+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createResponseHelper: op/execute id/10:
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2@467c7c33|#]

[#|2010-08-27T09:55:41.346+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createSystemExceptionResponse: op/execute id/10|#]

[#|2010-08-27T09:55:41.347+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|org.omg.CORBA.COMM_FAILURE:
vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3484)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:1054)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:144)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:92)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:357)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:265)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:631)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:650)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.write_octet_array(CDROutputObject.java:532)
at
com.sun.corba.ee.impl.servicecontext.UnknownServiceContextImpl.write(UnknownServiceContextImpl.java:78)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeMapEntry(ServiceContextsImpl.java:380)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeServiceContextsInOrder(ServiceContextsImpl.java:329)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.write(ServiceContextsImpl.java:304)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:210)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2364)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2327)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2251)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2028)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1703)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

#]

which is again logged several times until this last log:

[#|2010-08-27T09:55:41.366+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .getServiceContextsForReply: op/execute id/10:
SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected ishut
local=/10.58.59.119:3701 remote=/10.50.196.60:61207] ABORT true true]|#]

[#|2010-08-27T09:55:41.366+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .createResponseHelper: op/execute id/10:
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2@3ac6c26|#]

[#|2010-08-27T09:55:41.366+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleThrowableDuringServerDispatch: op/execute id/10:
cannot handle: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203
completed: No|#]

[#|2010-08-27T09:55:41.367+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleRequest: op/execute id/10: !Unable to render embedded object: File (ERROR) not found.!: RequestMessage|#]

[#|2010-08-27T09:55:41.368+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|java.lang.RuntimeException:
handleThrowableDuringServerDispatch: cannot create response.
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2002)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2037)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1978)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1703)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3462)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:3484)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:1054)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:144)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:92)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:357)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:265)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:631)
at
com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:650)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.write_octet_array(CDROutputObject.java:532)
at
com.sun.corba.ee.impl.servicecontext.UnknownServiceContextImpl.write(UnknownServiceContextImpl.java:78)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeMapEntry(ServiceContextsImpl.java:380)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.writeServiceContextsInOrder(ServiceContextsImpl.java:329)
at
com.sun.corba.ee.impl.servicecontext.ServiceContextsImpl.write(ServiceContextsImpl.java:304)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:210)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2364)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2327)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2251)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:2028)
... 18 more

#]

[#|2010-08-27T09:55:41.369+0200|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=19;_ThreadName=Thread-2;|CorbaMessageMediatorImpl(p:
thread-pool-1; w: 2): .handleRequest<-: op/execute id/10|#]

The client was started 2 times and there might be a mixing with the 2
executions. But nevertheless it is strange that after 1 hour the server has
desided to give up any attempt to inform the client about the failure; but the
client waits on.

Now first of all what's going wrong in the first place, why fails the request.
And secondly why is the client never aware of the failure.
I've some log files containing more detailed information but I don't know how to
upload them....

Thanks
Petra



 Comments   
Comment by petraleomue [ 27/Aug/10 ]

Created an attachment (id=4759)
partial server log file with ORBDebug=subcontract and ORBInitDebug=true

Comment by petraleomue [ 27/Aug/10 ]

Created an attachment (id=4760)
Client log with ORBDebug=transport

Comment by petraleomue [ 27/Aug/10 ]

Created an attachment (id=4761)
Client log full ORB log enabled

Comment by petraleomue [ 07/Sep/10 ]

The original problem was a classloading problem that wasn't reported to the
client and not logged at the server.
If server and client are running at the same maschine (client connects to
localhost) the error is reported from client to server and written to the
server's log file.
So perhaps this could be changed in such a way as to report the error even if
client and server are not running at the same maschine.





[GLASSFISH-8590] EJB over IIOP gets slower and slower then fails Created: 25/Jun/09  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v2.1.2
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: adam1jen Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issue Links:
Dependency
depends on GLASSFISH-8589 Injection fails with seperate web and... Resolved
Issuezilla Id: 8,590
Tags: 3_1-exclude

 Description   

I have a ServletContextListener that starts a java.util.Timer that calls an SSB
EJB method every ten minutes to see if reports need to be regenerated on the web
tier (the reports need to be on the web tier, so this can't be done with EJB
Timer Service).

I noticed over the course of an hour, the call to the remote method
isReadyForReportGeneration() gradually started to take more and more time.
Initially it returned within a few milliseconds, the second time it took a few
minutes, third time 10 minutes, forth time 10 minutes, then over 1/2 an hour
causing the following:

[#|2009-06-26T09:31:54.452+1000|WARNING|sun-appserver2.1|javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.transport|_ThreadID=13;_ThreadName=Timer-3;1800000;_RequestID=d8adab48-7c47-4cf5-97ce-16fac1d863d5;|"IOP00410219:
(COMM_FAILURE) Communications timeout waiting for response. Exceeded 1,800,000
milliseconds"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3180)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3195)
at
com.sun.corba.ee.impl.transport.CorbaResponseWaitingRoomImpl.waitForResponse(CorbaResponseWaitingRoomImpl.java:198)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.waitForResponse(SocketOrChannelConnectionImpl.java:1196)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.waitForResponse(CorbaMessageMediatorImpl.java:291)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:389)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:357)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:219)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:192)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at
com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
at
com.megajobindex.ejb._UnsecuredOperationsRemote_Remote_DynamicStub.isReadyForReportGeneration(com/megajobindex/ejb/_UnsecuredOperationsRemote_Remote_DynamicStub.java)
at
com.megajobindex.ejb._UnsecuredOperationsRemote_Wrapper.isReadyForReportGeneration(com/megajobindex/ejb/_UnsecuredOperationsRemote_Wrapper.java)
at
com.megajobindex.web.scheduling.ReportGenerationMonitor.run(ReportGenerationMonitor.java:122)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

#]

Initially I thought this could be my code in isReadyForReportGeneration() method
no closing a db connection or something, so I commented all the code out so that
the body of that method just became:

return false;

Same problem. This is using a seperate web and ejb glassfish instance, each on
fairly beefy machines (Intel Xeon Quad Core * 2 – so 8 cores) with 2Gb memory
assigned to each instance...and the timer thread is the only thread that's
accessing the EJB instance...so it's not under heavy load (under a load of 1
connection actually).

After the error above gets thrown the entire EJB layer becomes completely
unresponsive.

It's pretty easy...simply create an SSB in an EAR, deploy it on a glassfish
instance. Create a WAR with a ServletContextListener that spawns a timer thread
to call the ejb method. You should be able to use the same setup that you
create for issue 8589 (both these issues come from the same application)

This is a blocker on an application I'm attempting to move from dev to production.

Ubuntu Linux, JDK 1.6.0_14, glassfish-installer-v2.1-b60e-linux.jar



 Comments   
Comment by adam1jen [ 25/Jun/09 ]
      • Issue 8590 has been confirmed by votes. ***
Comment by adam1jen [ 25/Jun/09 ]

Added dependency to 8589

While it's not a strict dependency, it is for the test case.

Comment by adam1jen [ 09/Jul/09 ]

Changed the targeted milestone to 2.1.2 so that this bug doesn't get lost in
amongst all the v3 bugs/enhancements. It's a v2.1 P1 production bug so should
target a v2 branch and is specific to clustering, so as yet has no equivalent in v

Comment by adam1jen [ 13/Jul/09 ]

This has been verified as Linux only. This bug does not occur on windows machines.

Comment by adam1jen [ 16/Jul/09 ]

This bug seems to be only in certain Linux distros (namely Ubuntu). Have tested
CentOS and it works fine. Lowering priority to P3 as a work around now exists
(use CentOS or another distro)

Comment by ksak [ 11/Oct/09 ]

Marked v3_exclude

Comment by marina vatkina [ 08/Jun/10 ]

Needs evaluation from orb module

Comment by Ken Cavanaugh [ 06/Oct/10 ]

I'll take a look, but I'm not sure I can reproduce this.

Comment by Ken Cavanaugh [ 17/Nov/10 ]

No time to investigate for GF 3.1.





[GLASSFISH-15571] Create Resource Adapter Config is throwing an exception if jms is already started Created: 14/Jan/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: sumasri Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_2-exclude

 Description   

Start the JMS. In GUI, try to create a resource adapter config using jmsra and thread pool as "http-thread-pool".
It is throwing an exception in the server log.

Steps to reproduce the issue :

1)./bin/asadmin jms-ping
2) In GUI, create a resource adapter config with resource adapter name as jmsra and thread pool as http-thread-pool. Then, it throws an exception.

Exception in server log :

[#|2011-01-14T14:55:14.369+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|Thread-pool [ http-thread-pool ] not found|#]

[#|2011-01-14T14:55:14.370+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|An error occurred during instantiation of the work manager for resource-adapter [ jmsra ]
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:118)
at com.sun.enterprise.connectors.work.WorkManagerFactory.createWorkManager(WorkManagerFactory.java:125)
at com.sun.enterprise.connectors.work.WorkManagerFactory.getWorkManagerProxy(WorkManagerFactory.java:196)
at com.sun.enterprise.connectors.ConnectorRuntime.getWorkManagerProxy(ConnectorRuntime.java:1129)
at com.sun.enterprise.connectors.BootstrapContextImpl.initializeWorkManager(BootstrapContextImpl.java:161)
at com.sun.enterprise.connectors.BootstrapContextImpl.<init>(BootstrapContextImpl.java:103)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:126)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:211)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:345)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.reCreateActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:541)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.addResourceAdapterConfig(ResourceAdapterAdminServiceImpl.java:494)
at com.sun.enterprise.connectors.ConnectorRuntime.addResourceAdapterConfig(ConnectorRuntime.java:1195)
at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.deployResource(ResourceAdapterConfigDeployer.java:86)
at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.redeployResource(ResourceAdapterConfigDeployer.java:117)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.handleChangeEvent(ResourceManager.java:378)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.changed(ResourceManager.java:328)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:329)
at org.glassfish.javaee.services.ResourceManager.changed(ResourceManager.java:275)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:376)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:366)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:256)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:254)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.corba.ee.spi.orbutil.threadpool.NoSuchThreadPoolException
at org.glassfish.enterprise.iiop.util.S1ASThreadPoolManager.getThreadPool(S1ASThreadPoolManager.java:217)
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:111)
... 29 more



 Comments   
Comment by Jagadish [ 14/Jan/11 ]

ThreadPoolManager.getThreadPool() seems to throw the exception.

ThreadPoolManager only has "thread-pool-1" when the method "getThreadPool" is called.

Transferring to Ken for further investigation.

Steps to reproduce :

asadmin jms-ping
asadmin create-resource-adapter-config --threadpoolid http-thread-pool jmsra

will show the reported exception in server.log

Comment by Ken Cavanaugh [ 14/Jan/11 ]

It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector).
This class has a static initializer that reads the ThreadPool config data from
the iiop service and network listener config beans. But there is no way to
add a new ORB threadpool after the initial configuration is read.

It is also not clear to me from the test case how you expect "http-thread-pool" to be created.
Is this an ORB threadpool or a Grizzly threadpool? GF 3.1 has TWO distinct threadpool implementations currently.
Which one does create-resource-adapter-config expect to use?
How does the http-thread-pool get created if it does not already exist?

I am excluding this from 3.1 because I cannot investigate it or fix it before
the RC1 deadline. It is not even clear if this is something that should be fixed at this point.

Comment by Jagadish [ 17/Jan/11 ]

Hi Ken,

> It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector).
> This class has a static initializer that reads the ThreadPool config data from
> the iiop service and network listener config beans. But there is no way to
> add a new ORB threadpool after the initial configuration is read.

Yes, whenever we create a thread-pool, we restart the server.

> It is also not clear to me from the test case how you expect "http-thread-pool" to be created.
> Is this an ORB threadpool or a Grizzly threadpool?
Connector container uses ORB thread pool (work) API and hence its always ORB thread pool.
> GF 3.1 has TWO distinct threadpool implementations currently.
> Which one does create-resource-adapter-config expect to use?
ORB thread pool.
In GlassFish 2.x and before, a resource-adapter can use any of the configured thread-pools in the system.

> How does the http-thread-pool get created if it does not already exist?
http-thread-pool configuration is present in a all domains by default.

> I am excluding this from 3.1 because I cannot investigate it or fix it before
> the RC1 deadline. It is not even clear if this is something that should be fixed at this point.

I am able to create a new thread pool, restart server, configure the resource-adapter to use new thread pool successfully. However, I do not see http-thread-pool and admin-thread-pool in the list of thread pools of S1ASThreadPoolManager. Is this by design ?
If it is by design, probably we should document it.

eg: Following thread-pools are grizzly thread pools and will not be available for ORB thread pool clients/users.
http-thread-pool, admin-thread-pool

I am adding '3_1-release-notes' tag to the issue so that it is documented/release-noted.

Could you please provide appropriate documentation changes for the same ?

Comment by Jagadish [ 17/Jan/11 ]

Update : I see that IIOPUtils exluding thread-pools that are used by http-listener (network-listener) while initializing ORB thread-pools.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Jagadish [ 31/Mar/11 ]

There are two thread pool implementations from GlassFish 3.0 ie., grizzly based thread-pool and ORB based thread-pool.

"create-resource-adapter-config" takes a thread-pool id as parameter which is based on ORB thread-pool.
Also refer, create-thread-pool command to create new thread-pools.

ORB thread-pool, when initialized will verify whether an "thread-pool" is used by grizzly and will initialize the thread-pool only if grizzly is already not using the configuration.

So, there need to be a documentation stating that ORB thread pool manager will exclude any defined thread-pool configuration in the system if its already used by grizzly thread pool manager.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1. Release Notes.

Comment by Nazrul [ 21/Apr/11 ]

It would be useful to look into this issue during 3.1.1

Comment by scatari [ 25/Jun/11 ]

Marking it as to be considered after 3.1.1.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15490] IIOP failover Dev Test is failing Created: 07/Jan/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b37
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File orb-iiop-folb-multinode-build7.log    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP failover Dev Test is failing on multi node cluster, with secure admin enabled

Config 1: Single node, three instance cluster, with no secure admin: IIOP failover works fine.

Config 2: Two node, three instance cluster, with secure admin enabled: The tests fails with following exception:

-------------------------------

[failOverTest] result[50]= in1
Command stop-instance for instance in1
javax.ejb.NoSuchEJBException
at orb.folb._LocationBeanRemote_Wrapper.getLocation(orb/folb/_LocationBeanRemote_Wrapper.java)
at orbfailover.Main.failOverTest(Main.java:136)
at orbfailover.Main.main(Main.java:104)
Caused by: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 1398079490 No; nested exception is:
org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:269)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at orb.folb._LocationBeanRemote_Remote_DynamicStub.getLocation(orb/folb/_LocationBeanRemote_Remote_DynamicStub.java)
... 3 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:900)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:131)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:637)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:499)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:373)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:243)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
... 6 more
[failOverTest] FAIL

=========================



 Comments   
Comment by Harshad Vilekar [ 09/Jan/11 ]

The same test (with no changes) passed with latest nightly build.

Comment by Ken Cavanaugh [ 10/Jan/11 ]

As this is now passing, I'm closing this issue. I suspect there was a problem
with EJB deployment on a cluster in secure admin mode, which would result in
the observed exception.

Comment by Harshad Vilekar [ 18/Jan/11 ]

Reopening the issue, since the exception is seen intermittently with nightly hudson runs.

1. The pattern is:

  • The FailOver test fails when the instance - running on the remote node - is stopped.
  • The FailOver test works fine, when the instance - running on the same node as DAS node - is stopped.

2. The cluster state is looking fine:

$asadmin list-instances --long c1
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 6738 c1 running
in1 intg2t1000 8107 3474 c1 running
in3 localhost 8619 6630 c1 running
Command list-instances executed successfully.

3. OrbFailOver-ejb is deployed on the cluster, and looks fine:
------------------
$ asadmin list-applications c1
OrbFailOver-ejb <ejb>
------------------

Comment by Ken Cavanaugh [ 18/Jan/11 ]

Moving to next release: not a release blocker for 3.1.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15404] Add capability to dynamically add tracing using ORB tracing facility Created: 01/Jan/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

It would improve the ORB footprint and performance slightly to modify the tracing facility (TF) bytecode
instrumentation to modify ORB classes dynamically for phase II of the TF transformation.
Doing this requires using the redefineClasses method, which requires access to the Instrumentation API.
Unfortunately the only way to do this appears to be to use the attach API from tools.jar and
the VirtualMachine API. I suspect this is likely to be non-portable at some level, but fortunately GlassFish
has already dealt with the problem in the flashlight code. In fact, the public class
org.glassfish.flashlight.agent.ProbeAgentMain.getInstrumentation directly provides access to the
Instrumentation API. It looks like the EnableMonitoring command is close to what is required here,
but we may need to directly use the equivalent of attachAgent.






[GLASSFISH-15638] Show "restart required" status when IIOP service configuration / port is changed Created: 20/Jan/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b38
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Per Admin Guide, "Impact of Configuration Changes" section, Configuration Changes That Require Server Restart include: Managing IIOP services.

However, "restart required" is not indicated by Admin CLI/GUI when IIOP service configuration is changed.

Example Steps:

on Admin Console

Click Server Config - ORB - IIOP Listeners - orb-listener-1 - Listener Port - Change to "3702" - Save

Expected: Restart Required notification is displayed.



 Comments   
Comment by Anissa Lam [ 20/Jan/11 ]

Can you tell me which 'Admin Guide' and the location of this doc ?
Maybe this is a doc bug, i think most configuration change is dynamic now.

Comment by Harshad Vilekar [ 21/Jan/11 ]

The link to the Admin Guide that I got from the DOC team (included in GLASSFISH-15516) worked earlier - but is broken as of yesterday. Let's get the updated link from the Doc team (I just sent separate email to Paul).

If somebody can send out the list of the the configuration changes that are changed to "dynamic" as of 3.1 - that information will be very useful. Restart required notification is not generated for most of the config changes that are listed in the "Oracle GlassFish Server 3.0.1 Administration Guide" under section "Configuration Changes That Require Server Restart".

Comment by Harshad Vilekar [ 21/Jan/11 ]

Admin Guide:
> On 01/21/11 09:52, Paul M Davies (Oracle) wrote:
> Here's the link to this information in its new home on OTN: http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html

Comment by Anissa Lam [ 21/Jan/11 ]

I see. You were talking about the Admin Guide for 3.0.1.
The docs has been moved. It is now available under

http://download.oracle.com/docs/cd/E19798-01/

I see this bug has no component/owner and assigned to Nazrul.
I believe Tom should own this, look at this section
"http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html" and provide the list that actually requires server restart to the doc team.

I see this list is very out-dated.
Maybe the doc team has changed this list for 3.1 already, i don't know. If so, please use the 3.1 list and file bug accordingly.

Comment by Anissa Lam [ 21/Jan/11 ]

Where is the corresponding list for 3.1 ?
Harshad should be using the 3.1 list instead of those from 3.0.1 to file bug.

Comment by Harshad Vilekar [ 21/Jan/11 ]

That part of the doc is not updated since 3.0.1.

On 12/29/10 13:48, Paul Davies wrote:
> Hi Harshad,
>
> :
> :
> We have not updated Impact of Configuration Changes since 3.0.1, so you can refer to that for the current information.
>
> Regards,
> -Paul

Comment by Tom Mueller [ 21/Jan/11 ]

Reassigning to the orb category to determine whether changing the IIOP port requires a server restart in 3.1. For HTTP listener ports, a server restart is not necessary, so the documentation at the given link is definitely wrong. Just want to confirm whether this is also the case for the IIOP ports.

Comment by Tom Mueller [ 21/Jan/11 ]

If a server restart is not required when changing the IIOP ports, please change this to be a doc bug so that the documentation can be updated.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Changing IIOP ports definitely requires a server restart in the present implementation.
It's technically possible to change IIOP ports, but this requires ORB changes, as well as
some sort of notification mechanism between admin and the ORB. I know how to change the
ORB to support this, but I don't know how to hook something like this into admin.

In any case, this is not supported in GF 3.1, and the docs should reflect this.
Changing this to a doc bug as Tom suggested.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Oops, I mis-read Tom's comment before I made my last reply.
Changing ORB configuration requires server restart in GF 3.1.

How is this supposed to be changed in the admin CLI commands?
Assigning to Tom for further consideration.
If you want me to update the orb-listener commands, please tell me
how to do this.

Comment by Tom Mueller [ 24/Jan/11 ]

To trigger the "restart required" behavior, it is necessary for some code to detect that a change that has been made that cannot be processed without restarting, and for that code to create and send an UnprocessedChangeEvent. One way of doing this is to have a service that implements the ConfigListener interface, which has a "changed" method that takes an array of PropertyChangeEvent objects and returns list of UnprocessedChangeEvent objects. See this file for an example:

ejb/ejb-container/src/main/java/com/sun/ejb/containers/EJBTimerServiceConfigListener.java

Another way to do this is to explicitly inject the UnprocessedConfigListener class, and call its unprocessedTransactiveEvents method with a List of UnprocessedChangeEvents objects. See this file for an example of this:

core/logging/src/main/java/com/sun/enterprise/server/logging/LogManagerService.java

I suspect that this is what has happened. In earlier releases, a change to a Grizzly port required a server restart, and Grizzly took care of providing this notification. However, more recently, Grizzly no longer requires a restart to change a port number. For example, the HTTP port can be changed without a restart. However, if IIOP and the ORB still need a restart when the port changes, that could will now have to provide the notification of the unprocessed change event.

The documentation eventually needs to be cleaned up because changes to some ports require a restart, and changes to other ports do not. But the documentation generalized and says a restart is needed for all port changes.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

I don't have a ConfigListener in the ORB interface code, so I don't understand how any of this is
supposed to work.

  • Would I just need to create an implementation of ConfigListener inside an appropriate ORB bundle
    (orb-connector in this case), and annotate it as @Service? Is this automatically picked
    up by admin using hk2?
  • Presumably I would need a changed( PropertyChangeEvent[] ) method. How do I determine what the
    event is that I need to return in unprocessed events? It looks like I need to inject
    IiopListener and then look for event.getSource() of type IiopListener. The operation of
    interest on IiopListener is setPort. So what is event.getPropertyName in this case?

I think a can use a simple implementation here that simply returns everything passed
to the changed event as an unprocessed event, since nothing in the ORB is currently dynamically
updatable.

Comment by Tom Mueller [ 24/Jan/11 ]

Yes on creating the ConfigListener, except that something needs to reference the service in order to get it loaded. In the EJBTimerService, there is the following call that does this:

ejbContainerUtil.getDefaultHabitat().getComponent(EJBTimerServiceConfigListener.class);

See the EJBTimerService.java file.

It sounds like any event on an IiopListener could be made an UnprocessedChangeEvent.
I expect that the property name in the case of the port changing would be "port" since that is what is in the XML.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

One last question: is this fix needed for 3.1, or should we defer it to 3.2?

Comment by kumara [ 24/Jan/11 ]

This is arguably likely to cause confusion to the end users but is lower priority because –

1. port change is a one-time activity in most real deployments
2. After port change, a user is likely to try the application to verify that it works and will discover the problem.
3. Restart is a natural first step towards solving the problem.

I would recommend addressing it in next release and documenting in release notes that clusters/server instances need to be restarted for any configuration changes to IIOP service to take effect.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

Moving to 3.2 per Kumara's comment.

Should add some of the simple cases of ORB dynamic reconfiguration in that release in any case.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-4779] iiop-listener ip address ignored Created: 16/Apr/08  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: jarol1 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,779
Tags: 3_1-exclude

 Description   

In my domain.xml I have defined 2 additional unencrypted orb listeners on ports
3701 and 3702 on different IP addresses. But when I start glassfish, my settings
are ignored, and iiop service works only on 10.20.32.51 (on ports 3700, 3701,
3702 - I didn't want that!) even though I selected other IP addresses for other
listeners. Server has multiple network cards, 2 of them in bond. It has
10.20.32.51 (bond), 10.10.32.151 and 127.0.0.1. I need the iiop to work on all
IP addresses, but on different ports. Using 0.0.0.0 doesn't have the required
effect, since then I can't jndi from remote machine on 10.10.32.151.

<iiop-service client-authentication-required="false">
<orb max-connections="1024" message-fragment-size="1024"
use-thread-pool-ids="thread-pool-1"/>
<iiop-listener address="0.0.0.0" enabled="true" id="orb-listener-1"
port="3700" security-enabled="false"/>
<iiop-listener address="10.10.32.151" enabled="true" id="orb-listener-2"
port="3701" security-enabled="false"/>
<iiop-listener address="10.20.32.51" enabled="true" id="orb-listener-3"
port="3702" security-enabled="false"/>
<iiop-listener address="0.0.0.0" enabled="true" id="SSL" port="3820"
security-enabled="true">
<ssl cert-nickname="s1as" client-auth-enabled="false"
ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true"
tls-rollback-enabled="true"/>
</iiop-listener>
<iiop-listener address="0.0.0.0" enabled="true" id="SSL_MUTUALAUTH"
port="3920" security-enabled="true">
<ssl cert-nickname="s1as" client-auth-enabled="true"
ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true"
tls-rollback-enabled="true"/>
</iiop-listener>
</iiop-service>

This bug is present in both Glassfish V2ur2 and Glassfish V2ur1.



 Comments   
Comment by harpreet [ 20/Oct/08 ]

Please scrub issue and see if it is critical to v2.1.

Comment by Ken Cavanaugh [ 28/Oct/08 ]

The current ORBManager code uses the old LISTEN_SOCKET_PROPERTY to initialize
the acceptor list, and the old API does not support a hostname, so we do not
really support multiple network interfaces very well. The ORB actually supports
the needed functionality internally, and we simple need to add a new
transport SPI in TransportDefault, which can be used to create an appropriate instance
of SocketOrChannelAcceptorImpl. This can then be registered with the TransportManager
during ORB initialization using the GlassFish ORB configurator.

As this is not critical for GFv2.1, I am moving it to V3.

Comment by Ken Cavanaugh [ 30/Oct/08 ]

Moving to V3 (missed the target milestone update).

Comment by Ken Cavanaugh [ 30/Oct/08 ]

Still trying to remove from 9.1.1.

Comment by Ken Cavanaugh [ 22/Sep/09 ]

Moving to v3.1, although the new approach of creating acceptors
directly should support this much more easily than the old
properties-based approach.

Comment by Ken Cavanaugh [ 06/Oct/09 ]

Needs v3_exclude in status whiteboard to exclude from v3.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moved to v3.1.

Comment by chaoslayer [ 18/Feb/11 ]

This has been initially reported as GLASSFISH-16, back in 2005. So almost 6 years (!!!) and no solution for this problem?

So, GlassFish (including the upcoming 3.1 release) MUST secured externally. And still a risk is still there.

Please, guys, fix it.

Comment by chaoslayer [ 18/Feb/11 ]

Also I've noted, that the one that is initialized lazy actually IS bound to a specific interface:

tcp6 0 0 ::1:3700 :::* LISTEN 1000 28061662 5202/java





[GLASSFISH-4257] Investigate ways to speed up serialization Created: 25/Feb/08  Updated: 17/Oct/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,257

 Description   

Continue investigations on how to speed up Java serialization through
alternate protocols for serialized data. The ORB support serialization
over CDR, but this item is mainly aimed at finding faster encodings,
particularly encodings that are better parallelizable than CDR or the
standard Java serialization protocol. Another option to consider for this
feature is the runtime generation of serialization classes for specific
Serializable objects.



 Comments   
Comment by Ken Cavanaugh [ 26/Feb/08 ]

Should be P2 and on the PRD.

Comment by Ken Cavanaugh [ 22/Sep/09 ]

Not for v3.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moving to P3 due to lack of resources. Also moving to V3.1.





[GLASSFISH-3762] EJB deployed on the Glassfish on server with multiple IP Created: 11/Oct/07  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 9.1pe
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: falsehood Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File loader_stacktrace.zip     PNG File MultipleIPBugEn.png    
Issuezilla Id: 3,762
Tags: 3_1-exclude

 Description   

Server OS: Linux debian (sarge), kernel 2.6.8-3-386, libc6 2.3.2.ds1-22
Glassfish V2
java : version "1.6.0", Java(TM) SE Runtime Environment (build 1.6.0-b105)
Client OS : Windows XP SP2

I can't connect to EJB, deployed on the Glassfish, via IIOP.
It has multiple IP addresses : LAN 192.x.x.x and Internet 217.x.x.x.
I set two IIOP listeners. The first listener on 192.x.x.x (port 9411), the
second - on 217.x.x.x (port 8811).
If client is trying to connect from the LAN, the connection is successful. Two
connections are opened (both to the 192.x.x.x:9411). It is clear from the netstat.
If client is trying to connect from the Internet, its connection is fail. The
first connection is established correctly (to the 217.x.x.x:8811), but the
second one is trying to connect 192.x.x.x:8811 or 192.x.x.x:9411, which is not
accessible from the Internet since it is internal network IP.



 Comments   
Comment by gfbugbridge [ 11/Oct/07 ]

<BT6616065>

Comment by Mahesh Kannan [ 25/Oct/07 ]

Can the submitter provide the server.log containing the stacktrace? Also, it
will be helpful if the snippet of the client code can be posted

Comment by Mahesh Kannan [ 29/Oct/07 ]

Have asked the submitter to provide stacktrace and client code snippet. In any
case this doesn't even sound like an ejb container bug. Transferring this to ORB
for their evaluation and since this is also not a show stopper, adding as91ur1-na

Comment by falsehood [ 30/Oct/07 ]

Created an attachment (id=1235)
problem stacktace

Comment by falsehood [ 30/Oct/07 ]

Created an attachment (id=1236)
graphical description of the problem

Comment by falsehood [ 30/Oct/07 ]

Stacktrace and graphical description of the problem had been attached.

Comment by Ken Cavanaugh [ 06/Nov/07 ]

This has become a rather common feature request, and I think we'll
implement a solution for GFv3. Basically, this is yet another example
of why NAT is a very bad idea, but we are stuck with it until the world
moves to IPv6.

Given that we need to do something to handle this, what I plan is to add
a capability of tagging addresses in an IOR with a domain, adding a
configurable domain to the ORB, and then modifying the
CorbaContactInfoListIterator to only look at those ContactInfos that
correspond to addresses in the same domain as the client ORB. For outside
clients, we would default this, whereas inner clients (behind the firewall)
would need to set a domain (probably just an int).

Since this is mostly an ORB issue, I'm re-assigning it to myself and changing
this to an enhancement for V3.

Comment by Ken Cavanaugh [ 06/Nov/07 ]

Should also mark this started.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Considering for v3.1.





[GLASSFISH-2788] Transaction support need a mechanism to categorize object references Created: 06/Apr/07  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 9.1pe
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 2,788
Tags: 3_1-exclude

 Description   

TBD after creation of issue



 Comments   
Comment by Ken Cavanaugh [ 06/Apr/07 ]

(from Sankara)
> Ken,
>
> The original fix for just differentiating between EJB and non EJB calls is
not working as there are some scenarios in which the transaction needs to be
propagated even for non EJB calls (they are not user calls but some systems calls).
>
OK, let's look at the details here. I think what we want is some sort of
categorization mechanism
for objects. In fact, let's just call this Category. We don't need many of
these, and the only
needed information is the Category itself, so let's just use a simple int for
the category value.

There is one reserved Category (probably value 0) which is used for POAs that
are NOT created
by the app server. The app server can manage the categories, so for example we
could have:

Category 1 EJB
Category 2 Naming

and anything else we might need. Note that this also solves the
isEjbAdapterName performance
issue: we would just use simple integer comparison, rather than strings to
determine the sort
of invocation we have.

We also need to decide where the information is set, and where it is needed.
The only reasonable
place to set the information is in IORInterceptor.establish_components, using
the IORInfo that
is passed to establish_components. We already have an extension interface
(IORInfoExt) that
our implementations of IORInfo also implement. Right now it just supports
getServerPort and
getObjectAdapter. We can add a setCategory( int ) method on IORInfoExt that can
only be
called during establish_components. We might as well add int getCategory() here
as well.
Obviously the category itself is stored in the ObjectAdapter, so alternatively
we could have the
getter on the ObjectAdapter. However, the ObjectAdapter is basically immutable,
so the setter
needs to be on IORInfo and only valid during establish_components, which is when
the ObjectAdapter
(and IORTemplate) are constructed.

The value of the category is also needed in the request interceptor. Since
the transaction support requires the category on the client side, we
need to put the category in the IOR, probably as a tagged component
(I could put it in the ObjectKeyTemplate, but that would require a new
IOR version, and I'd rather not do that).
In any case, we would simply add the int getCategory() method to the RequestInfoExt
interface, which is implemented by both ClientRequestInfoImpl and
ServerRequestInfoImpl.
On the server side, getCategory just looks into the ObjectAdapter and returns
the category.
On the client side, the method either throws a NO_IMPLEMENT exception, or else
pulls the
category out of a (cached) unmarshaled tagged component.

Comment by Ken Cavanaugh [ 26/Apr/07 ]

Downgrading to P4: insufficient time to do this enhancement
for Beta 3.

Comment by Ken Cavanaugh [ 25/Oct/07 ]

Will implement this for GFv3.

Comment by Ken Cavanaugh [ 06/Feb/08 ]

Moved target to V3.

Comment by Ken Cavanaugh [ 06/Feb/08 ]
      • Issue 4086 has been marked as a duplicate of this issue. ***
Comment by Ken Cavanaugh [ 06/Feb/08 ]

Priority should be P3 on this.

Comment by Ken Cavanaugh [ 12/Feb/08 ]

Marked for inclusion in PCD.

Comment by Ken Cavanaugh [ 16/Mar/10 ]

This request has apparently gone away, so I am closing it.

Comment by Ken Cavanaugh [ 16/Mar/10 ]

Re-opening issue at Marina's request. 11174 will be marked as a duplicate of
this issue.

Comment by Ken Cavanaugh [ 16/Mar/10 ]

Moving back to STARTED state.

Comment by Ken Cavanaugh [ 16/Mar/10 ]
      • Issue 11174 has been marked as a duplicate of this issue. ***
Comment by Ken Cavanaugh [ 23/Mar/10 ]

This is desired by the transactions team for v3.1.





[GLASSFISH-16661] Glassfish v3.1 b43 build does not respect transactional service context in the corba call that is sent from Geronimo corba server Created: 16/May/11  Updated: 23/Dec/11

Status: In Progress
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: forrestxm Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 10.04
Oracle JDK 1.6.0_23


Tags: 3_1_1-scrubbed, 3_1_2-exclude, corba, interoperability, transaction

 Description   

Steps to reproduce this error:
In a CTS environment,
1. Deploy the txbean_ejbEAR.ear to glassfish v3.1 b43
2. Deploy the txbean_webEAR.ear to geronimo 3.0
3. Open a browser to access url http://localhost:8080/txbean_web/TxBeanServlet

You will see the "testresult=false" that means glassfish as the corba server side does not see the global transaction set by corba client side by Geronimo, allow the corba call on a method with transaction attribute is "never".

However, glassfish v2 can handle the same corba call from Geronimo 3.0, throws the expected RemoteException to Geronimo side.

BTW, Geronimo 3.0 only supports custom stream format version 1 for RMI-IIOP stream.



 Comments   
Comment by Ken Cavanaugh [ 18/May/11 ]

Transactions problem: assigning to Marina.

Comment by marina vatkina [ 01/Jun/11 ]

To be able to look at any details, please provide:

  • the ear file (and the sources if possible);
  • the instructions on the geronimo setup and deployment;
  • any extra steps on GF side (if any).
Comment by marina vatkina [ 13/Jul/11 ]

An update:

It seems like GF TM doesn't recognize an imported transaction from Geronimo.

Debugging the test shows that the context is null on my end (InterceptorImpl.receive_request is called, not
InterceptorImpl.receive_request_service_contexts by ORB). On the other hand, GF client-to-server tx propagation works correctly, and this is what I'm comparing with.

It's not clear (yet) where the actual error is...

Comment by marina vatkina [ 16/Jul/11 ]

Harshad is looking at the ORB behavior. So reassigning to him for now.

Comment by Harshad Vilekar [ 14/Dec/11 ]

Fix is committed to 3.1.2 (revision 50410) and trunk (revision 50438).
WebLogic - GF Tx interop tests PASS with the fix. However, Geronimo - GF test is still failing.

Comment by Harshad Vilekar [ 15/Dec/11 ]

Geronimo team is reviewing the fix. Awaiting confirmation.

Comment by forrestxm [ 15/Dec/11 ]

Can we have the fixed jar(s) directly for GF 3.1_b43 build? So that I can apply it to the existing GF 3.1_b43 installation to validate the fix.

Thanks!

Forrest

Comment by Harshad Vilekar [ 15/Dec/11 ]

It'll be best to test using full latest promoted GF 3.1.2 build.

There are various other changes in the jars since 3.1_b43.
Update jar is: glassfish3/glassfish/modules/orb-iiop.jar.

Comment by forrestxm [ 15/Dec/11 ]

Tried glassfish-3.1.2-b14.zip download from http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/ with geronimo 3.0-beta-1 release, still the same exception happen, no expected remote exception thrown from glassfish to geronimo.

Any more comments?

Forrest

Comment by marina vatkina [ 16/Dec/11 ]

Thank you for testing. We are still looking at the possible cause...





[GLASSFISH-16626] java.lang.ClassNotFoundException: javax.validation.groups.Default: java.net.MalformedURLException: Unknown protocol: osgi Created: 12/May/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Vetle Leinonen-Roeim Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File LettersOrDigits.java    
Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

When propagating a javax.validation.ConstraintViolationException from
a remote EJB to a front-end server, that is triggered from a custom
constraint validation (using a custom validation annotation), I get
the following stack trace:

Caused by: java.lang.ClassNotFoundException:
javax.validation.groups.Default: java.net.MalformedURLException:
Unknown protocol: osgi
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:325)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:628)
at com.sun.corba.ee.impl.orbutil.RepIdDelegator.getClassFromType(RepIdDelegator.java:169)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1439)
... 174 more

On the remote server, the stack trace is:

Caused by: javax.validation.ConstraintViolationException: validation
failed for classes [org.example.model.TextId] during update time for
groups [javax.validation.groups.Default, ]
at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:132)
at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreUpdate(BeanValidationEventListener.java:79)
at org.hibernate.action.EntityUpdateAction.preUpdate(EntityUpdateAction.java:236)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:87)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:268)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:260)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:180)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1206)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:791)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.flush(EntityManagerWrapper.java:418)
...

As far as I can tell, there should be no reason it should fail to find
the javax.validation.groups.Default class, so the error seems to be
triggered by something else.

I will attached the code for the custom constraint annotation.



 Comments   
Comment by marina vatkina [ 13/May/11 ]

This seems like an orb error

Comment by Ken Cavanaugh [ 18/May/11 ]

There are some problems with the handling of the special
osgi:// URLs the ORB uses to handle passing value types between
OSGi containers. However, this does not work if there is no
OSGi container on one end or the other of the remote call.
This needs to be fixed.

No time to fix in 3.1.1.





[GLASSFISH-16322] Fix ORB FindBugs issues Created: 06/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are currently around 160 low and medium priority FB issues in the ORB workspace.
We should fix most of these for GF 3.2.






[GLASSFISH-16324] corba-orb-iiop-folb-devtest suite: two tests are failing Created: 06/Apr/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File Test14762.html     HTML File Test15768.html    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Following two dev tests are failing on Hudson.

Test 15768 FAILED:

[Root exception is javax.naming.NameNotFoundException: No object bound to name java:comp/env/ejb]
==============================================

Test 14762 FAILED:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at testtools.Base.run(Base.java:235)
at orbfailover.Main.main(Main.java:375)
Caused by: javax.ejb.EJBException: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446337 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: intgv880-1; port: 11037 vmcid: OMG minor code: 1 completed: No
at orb.folb._LocationBeanRemote_Wrapper.getLocation(orb/folb/_LocationBeanRemote_Wrapper.java)
at orbfailover.Main.invokeMethod(Main.java:172)
at orbfailover.Main.test14762(Main.java:545)
... 6 more
Caused by: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446337 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: intgv880-1; port: 11037 vmcid: OMG minor code: 1 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:259)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at orb.folb._LocationBeanRemote_Remote_DynamicStub.getLocation(orb/folb/_LocationBeanRemote_Remote_DynamicStub.java)
... 9 more
Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: intgv880-1; port: 11037 vmcid: OMG minor code: 1 completed: No
at sun.reflect.GeneratedConstructorAccessor46.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy44.connectFailure(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:194)
... 12 more
Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
... 17 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500)
at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:110)
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:325)
... 18 more
==============================================

See attached hudson logs for details.



 Comments   
Comment by scatari [ 24/May/11 ]

Will be considered for the next release.





[GLASSFISH-16315] LAZY loading on attributes causes IOP00710285: (INTERNAL) A reflective tie got an error while invoking method ... Created: 05/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b22
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: laps Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.0.1 (build 22)
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)


Tags: 3_1_1-scrubbed, 3_1_2-exclude, IOP00710285, IllegalArgumentException, ReflectiveTie, corba, lazy, orb, serialization

 Description   

Having the following Entity :

@Entity
public class MyEntity implements Serializable {

private static final long serialVersionUID = 1L;

@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private Long id;

/* MyLazyEntity : simple entity */
@ManyToOne(fetch = FetchType.LAZY)
private MyLazyEntity lazyEntity;

/* Getters and setters */
}

When I make a new instance client side (in a JWS environnement) :

MyEntity me = new MyEntity();
getMyEJBRemote().saveMyEntity(me);

I have the following error (server side) :

[#|2011-04-05T17:52:56.018+0200|WARNING|glassfish3.0.1|javax.enterprise.resource.corba.ee.CORBA.rpc.presentation|_ThreadID=34;_ThreadName=Thread-1;|"IOP00710285: (INTERNAL) A reflective tie got an error while invoking method saveMyEntity on class ...MyEJBRemote_Remote"
org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 285 completed: No
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.invocationErrorInReflectiveTie(ORBUtilSystemException.java:7716)
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.invocationErrorInReflectiveTie(ORBUtilSystemException.java:7736)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:152)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)
... 12 more

#]

And client-side (JWS) :
javax.ejb.EJBException: java.rmi.RemoteException: CORBA INTERNAL 1398079773 No; nested exception is:
org.omg.CORBA.INTERNAL: ---------BEGIN server-side stack trace---------
org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 285 completed: No
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.invocationErrorInReflectiveTie(ORBUtilSystemException.java:7716)
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.invocationErrorInReflectiveTie(ORBUtilSystemException.java:7736)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:152)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 285 completed: No
at ...MyEJBRemote_Wrapper.saveMyEJB(.../.../_MyEJBRemote_Wrapper.java)
at ...save(....java:509)
...

When I start Glassfish in debug mode, I can't get into my EJB method.
Important : When start in localhost, I have not this problem, event if I start the application in my Eclipse environment.

If I remove (fetch = FetchType.LAZY) from lazyEntity anotations, everything becomes ok.

After looking for previously posted issues, I found two old ones :
http://java.net/jira/browse/GLASSFISH-1081
http://java.net/jira/browse/GLASSFISH-1442
but they are a bit outdated (from 2007) ; so I think the problem is not the same.



 Comments   
Comment by Ken Cavanaugh [ 18/May/11 ]

No time to fix in 3.1.1





[GLASSFISH-16064] javax.ejb.EJBException Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002 Created: 21/Feb/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b43
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: lft Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

$ java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

$ uname -a
Linux 2.6.18-194.17.4.el5 #1 SMP Mon Oct 25 15:50:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Often I see following messages in server.log:

[#|2011-02-21T14:31:11.233+0300|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=142;_ThreadName=Thread-1;|A system e
xception occurred during an invocation on EJB ChukchiManSlotMachineBean method public byte openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(byte)
javax.ejb.EJBException
at openbox.session._SessionFacade_Wrapper.setSessionData(openbox/session/_SessionFacade_Wrapper.java)
at openbox.core.component.GameComponent.setData(GameComponent.java:217)
at openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(ChukchiManSlotMachineBean.java:345)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4155)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5347)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy268.setPickedLineCount(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy189.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:86)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
at com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
at com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:574)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at openbox.session._SessionFacade_Remote_DynamicStub.setSessionData(openbox/session/_SessionFacade_Remote_DynamicStub.java)
... 32 more
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 41 more

#]


 Comments   
Comment by Ken Cavanaugh [ 21/Feb/11 ]

This is logged at FINE level. If you enabled FINE level logging, you will see more
log messages, and those from the ORB will have stack traces. This is not a bug.

Did you observe any failures, or are you just reporting a log message?

Do you have FINE logging enabled, either for everything, or for logger
javax.enterprise.resource.corba?

Comment by marina vatkina [ 21/Feb/11 ]

Let's investigate this - the user reported a WARNING in the log.

Comment by marina vatkina [ 21/Feb/11 ]

Are there any other messages in the log? What kind of EJBs are used in this call stack?

Comment by lft [ 24/Feb/11 ]

This message can repeat several times.
The EJBs are staetful.

Comment by marina vatkina [ 24/Feb/11 ]

Can it be that you are trying to access a SFSB instance after it was discarded because of an exception in the previous call?

Comment by lft [ 27/Feb/11 ]

Right now I have only one occurance of this exception in logs (old server logs was cleared). And there is another exception above this one - IOP00710134, that I reported in another thread, - but it's related to another bean. There is no another exceptions related to bean that produced IOP02500002.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15984] Validation error in remote EJB gives ClassNotFoundException: ... : Unknown protocol: osgi Created: 15/Feb/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1, 3.1_b41
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: andersaab Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux, windows


Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

When a validation error occurs in a remote ejb (at least with org.hibernate.validator.constraints.Length), this results in the following stacktrace:

[#|2011-02-15T10:26:46.765+0100|WARNING|glassfish3.1|javax.enterprise.resource.corba.ORBUtil|_ThreadID=21;_ThreadName=Thread-1;|IOP00810013: Could not find class org.hibernate.validator.constraints.Length in CDRInputStream.readClass
org.omg.CORBA.MARSHAL: WARNING: IOP00810013: Could not find class org.hibernate.validator.constraints.Length in CDRInputStream.readClass vmcid: OMG minor code: 13 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy285.cnfeReadClass(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1441)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1085)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.defaultReadObjectDelegate(IIOPInputStream.java:596)
at com.sun.corba.ee.impl.io.InputStreamHook.defaultReadObject(InputStreamHook.java:233)
at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:312)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.util.Utility.readAbstractAndNarrow(Utility.java:1026)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2157)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:345)
at java.util.HashSet.readObject(HashSet.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.ExceptionHandlerImpl$ExceptionRWRMIImpl.read(ExceptionHandlerImpl.java:180)
at com.sun.corba.ee.impl.presentation.rmi.ExceptionHandlerImpl.readException(ExceptionHandlerImpl.java:290)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readException(DynamicMethodMarshallerImpl.java:502)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:205)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at no.evote.service._OperatorService_Remote_DynamicStub.updateOperator(no/evote/service/_OperatorService_Remote_DynamicStub.java)
at no.evote.service._OperatorService_Wrapper.updateOperator(no/evote/service/_OperatorService_Wrapper.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at no.evote.service.cache.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:80)
at no.evote.service.cache.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:110)
at $Proxy323.updateOperator(Unknown Source)
at no.evote.presentation.OperatorController.saveOperator(OperatorController.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43)
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:148)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.DisableCachingFilter.doFilter(DisableCachingFilter.java:28)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.SelectRoleFilter.doFilter(SelectRoleFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.CookieFilter.doFilter(CookieFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.CSRFFilter.doFilter(CSRFFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at net.balusc.http.multipart.MultipartFilter.doFilter(MultipartFilter.java:78)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.saml.SAMLAccessFilter.doFilter(SAMLAccessFilter.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.presentation.MonitorFilter.doFilter(MonitorFilter.java:25)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.presentation.ForceLocaleFilter.doFilter(ForceLocaleFilter.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.hibernate.validator.constraints.Length: java.net.MalformedURLException: Unknown protocol: osgi
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:325)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:628)
at com.sun.corba.ee.impl.orbutil.RepIdDelegator.getClassFromType(RepIdDelegator.java:169)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1439)
... 182 more

#]

It has been around for a while, also discussed in the forum by someone else:
http://www.java.net/forum/topic/glassfish/glassfish/jpa-20-validaton-exceptions-and-unknown-protocol-osgi-0



 Comments   
Comment by Ken Cavanaugh [ 15/Feb/11 ]

Much too late to fix in 3.1.

The osgi: protocol is one I added in GF 3.0 to use in a codebase
where the sender and receiver are running under OSGi. The tradtional
RMI-style classpath does not work in this environment because
there is no classpath in OSGi. Instead, I defined a
osgi://<bundle name>:<version> URL to allow the receiver to find
the appropriate OSGi bundle in which to locate the class from the
class name passed in the value type that is being unmarshaled.

Unfortunately it appears that I did not find all the places in the
ORB that need to be modified in this case. It is also a bit hard
to set up an ORB-level OSGi-based regression test, but I really need
to take the time to do this.

Comment by Ken Cavanaugh [ 15/Feb/11 ]

It looks like the problem is a missing call to the classCodeBaseHandler in readClass. The
code is present in the more common case of reading a valueType (see CDRInputStream_1_0.getClassFromString
starting at line 2267 in the GF 3.1 ORB code). But it's missing in readClass.
Looks like the fix is basically to add:

ClassCodeBaseHandler ccbh = orb.classCodeBaseHandler() ;
if (ccbh != null) {
String className = repositoryID.getClassName() ;
Class<?> result = ccbh.loadClass( codebaseURL, className ) ;

if (result != null)

{ return result ; }

}

in readClass after the repIdStrings.getFromString(classRepId) call in readClass.

5 minutes to fix, 2 days to write a suitable regression test .

Comment by jdbuys [ 30/Mar/11 ]

I implemented the fix on our side but we still get the same error.

Do you have any other ideas?

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15975] lazy-init attribute missing from admin console Edit IIOP Listener page Created: 14/Feb/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

There isn't any way to view or edit the lazy-init setting for the IIOP listener from the admin console.



 Comments   
Comment by Anissa Lam [ 14/Feb/11 ]

This sounds like a new attribute added in iiop-listener, not sure if this is since 3.0 or 3.1.
The module owner should have contacted GUI regarding this change so that it can be incorporated in the GUI page.

When looking at config-api, I see that there is only get() method, but not set() for this attribute
@Attribute(defaultValue="false", dataType=Boolean.class)
String getLazyInit();

Is this a read-only attribute ?
Please confirm or fix this. Transfer to 'orb'.

Comment by Tom Mueller [ 14/Feb/11 ]

The IiopListener config bean has the following code:

/**

  • Sets the value of lazyInit property
    *
  • Specify is this listener should be started as part of server startup or not
    *
  • @param value true if the listener is to be started lazily; false otherwise
    */
    void String(boolean value);

It looks like this "String" method was supposed to be a "setLazyInit" method - maybe a typo?

Comment by Ken Cavanaugh [ 14/Feb/11 ]

This was added in 3.0. I'm not sure who was working on the IiopListener class at that
point, but it belongs to the orb now. I think Tom's comment is correct, and
the method should be

void setLazyInit( boolean value )

This is probably not worth fixing this late in 3.1. I'm marking this issue for inclusion
in the release notes.

I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Comment by Anissa Lam [ 14/Feb/11 ]

>> I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Do you mean the default value or out-of-box value ? They are different.
And is there a reason why default value is different than out-of-box value ? This is always very confusing to user when this happen.

Comment by Ken Cavanaugh [ 14/Feb/11 ]

I don't know what the difference is between default and out-of-the-box.
I just know that I always see lazy-init="true" for the orb-listener-1
IIOP listener in the config.xml file.

Comment by Tom Mueller [ 14/Feb/11 ]

Default is the value that is in the config bean Java source code, in this case "false".

Out-of-the-box is the value that is in the domain.xml template file, in this case "true" for orb-listener-1 and "false" for SSL and SSL_MULTIAUTH.

If a user clicks "New" in the admin console or runs the create-iiop-listener command (which also doesn't provide any way to set lazy-init), the user gets the default value, i.e., "false".

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Tom Mueller [ 24/Mar/11 ]

For the release notes:

The problem is that a user cannot set the lazy-init value for an IIOP listener from either the console or the CLI. Note that even the asadmin "set" command cannot be used to change the value. The only way to workaround this issue is to edit the domain.xml file directly. The domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" lazy-init="true"></iiop-listener>

In this case, the lazy-init value can be changed to false.

Or, the domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0"></iiop-listener>

Here, the default value of false is in effect. To change it to true, add:

lazy-init="true"

to the iiop-listener element.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Removed "need more info" tag, added "release note added" tag.

Comment by Nazrul [ 21/Apr/11 ]

Given that there is no way to manage lazy-init attribute using CLI and GUI, it would be useful to consider fixing this issue during 3.1.1

Comment by scatari [ 23/Jun/11 ]

Any GUI change in 3.1.1 requires recertification for 508 compliance that is too late to consider. Marking for next release.

Comment by Anissa Lam [ 23/Jun/11 ]

Before it gets to GUI, the backend needs to be fixed first.
No one has fixed the config bean code to allow setting of the value. I still see:

  /**
     * Sets the value of lazyInit property
     *
     * Specify is this listener should be started as part of server startup or not
     *
     * @param value true if the listener is to be started lazily; false otherwise
     */
    void String(boolean value);

Until this is fixed, GUI can't do anything.
When the above is fixed, then this can be assigned to GUI to add the UI.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-17112] CORBA connection broken by PC suspend mode Created: 27/Jul/11  Updated: 10/Jul/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_b11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mkarg Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE


Tags: 3_1_2-exclude

 Description   

I am running GFv3.1.1_b11 on a Win7 workstation for development. On the same workstation I have started ACC to run my Swing based client. It works fine. Then I have told the PC to go to suspend mode. After I woke it up again, the client was still useable, but the client's console contained this message:

SCHWERWIEGEND: Exception in ExplorerApplication.ping: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446344 Maybe; nested exception is:
org.omg.CORBA.COMM_FAILURE: FEIN: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe

I was able to reproduce this two times.

As suspend mode is nothing particular new or extraordinary, there should be no such message but instead the client should silently reconnect after waking up. In fact, I think that there is nothing broken at all but CORBA just assumes a lost connection since the time since the last network packet is longer than expected (since the workstation was sleeping). So a solution could be as simple as: Trying another attempt before complaining!



 Comments   
Comment by mkarg [ 07/Oct/11 ]

Can reproduce frequently by just going into hibernation mode and waking up again after some time. Really nasty as end users will see that and call the help desk each time.

Comment by mkarg [ 10/Jul/12 ]

Any comments?





[GLASSFISH-16989] Glassfish RI is not conforming to the Corba 2.3.1 specification. Created: 07/Jul/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lancea Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

Glassfish V3 is not conforming to the Corba 2.3.1 specification. This did not happen with Glassfish v2.x

From the GIOP stream (see the challenge text), we can see the GIOP stream version is 1.2, and this is a custom marshal of RMI valuetype.

According to
1. The section EE.7.2.2 "EJB interoperability protocol—The EJB interoperability protocol is based on IIOP (GIOP 1.2) and the CSIv2 CORBA Secure Interoperability specification. The EJB interoperability protocol is defined in the EJB specification."
2. The Common Object Request Broker: Architecture and Specification, version 2.3.1, 1999, "The chunked encoding is required for custom marshaling and truncation."

We expect chunked encoding for the custom marshal, however, the RI sent us the GIOP stream without chunking for implicit super class valuetype. When executing the test case , which does EJB corba call from our appserver to glassfish to get a user defined exception.
we get the failure as the separated failures log. After debugging into this failure, we get the GIOP stream that Glassfish sends to our appserver like following:

47 49 4f 50 01 02 02 01 00 00 03 f4 00 00 00 14 "GIOP............"
00 00 00 01 00 00 00 02 4e 45 4f 00 00 00 00 02 "........NEO....."
00 14 00 00 00 00 00 0f 00 00 00 18 00 00 00 01 "................"
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................"
00 00 00 00 00 00 00 00 00 00 00 2d 49 44 4c 3a "...........-IDL:"
6f 72 67 2f 61 70 61 63 68 65 2f 67 65 72 6f 6e "org/apache/geron"
69 6d 6f 2f 63 6f 72 62 61 74 65 73 74 2f 55 73 "imo/corbatest/Us"
65 72 45 78 3a 31 2e 30 00 00 00 00 7f ff ff 0b "erEx:1.0........"
00 00 01 0e 66 69 6c 65 3a 2f 68 6f 6d 65 2f 66 "....file:/home/f"
6f 72 72 65 73 74 78 6d 2f 74 63 6b 64 61 74 61 "orrestxm/tckdata"
2f 72 69 2f 33 2e 30 2f 67 6c 61 73 73 66 69 73 "/ri/3.0/glassfis"
68 76 33 2f 67 6c 61 73 73 66 69 73 68 2f 64 6f "hv3/glassfish/do"
6d 61 69 6e 73 2f 64 6f 6d 61 69 6e 31 2f 61 70 "mains/domain1/ap"
70 6c 69 63 61 74 69 6f 6e 73 2f 63 6f 72 62 61 "plications/corba"
68 65 6c 6c 6f 62 65 61 6e 5f 65 6a 62 5f 65 61 "hellobean_ejb_ea"
72 32 2f 63 6f 72 62 61 68 65 6c 6c 6f 62 65 61 "r2/corbahellobea"
6e 5f 65 6a 62 5f 6a 61 72 2f 20 66 69 6c 65 3a "n_ejb_jar/ file:"
2f 68 6f 6d 65 2f 66 6f 72 72 65 73 74 78 6d 2f "/home/forrestxm/"
74 63 6b 64 61 74 61 2f 72 69 2f 33 2e 30 2f 67 "tckdata/ri/3.0/g"
6c 61 73 73 66 69 73 68 76 33 2f 67 6c 61 73 73 "lassfishv3/glass"
66 69 73 68 2f 64 6f 6d 61 69 6e 73 2f 64 6f 6d "fish/domains/dom"
61 69 6e 31 2f 67 65 6e 65 72 61 74 65 64 2f 65 "ain1/generated/e"
6a 62 2f 63 6f 72 62 61 68 65 6c 6c 6f 62 65 61 "jb/corbahellobea"
6e 5f 65 6a 62 5f 65 61 72 32 2f 63 6f 72 62 61 "n_ejb_ear2/corba"
68 65 6c 6c 6f 62 65 61 6e 5f 65 6a 62 5f 6a 61 "hellobean_ejb_ja"
72 00 00 00 00 00 00 52 52 4d 49 3a 6f 72 67 2e "r......RRMI:org."
61 70 61 63 68 65 2e 67 65 72 6f 6e 69 6d 6f 2e "apache.geronimo."
63 6f 72 62 61 74 65 73 74 2e 55 73 65 72 45 78 "corbatest.UserEx"
63 65 70 74 69 6f 6e 3a 30 43 45 38 43 45 45 38 "ception:0CE8CEE8"
36 39 46 31 39 30 32 45 3a 43 45 30 44 37 41 37 "69F1902E:CE0D7A7"
37 45 43 42 37 39 34 32 38 00 00 00 00 00 00 0c "7ECB79428......."
01 01 00 00 ff ff ff ff ff ff fe 84 7f ff ff 0a "................"
00 00 00 23 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f "...#IDL:omg.org/"
43 4f 52 42 41 2f 57 53 74 72 69 6e 67 56 61 6c "CORBA/WStringVal"
75 65 3a 31 2e 30 00 00 00 00 00 3e 00 00 00 3a "ue:1.0.....>...:"
fe ff 00 54 00 68 00 69 00 73 00 20 00 69 00 73 "...T.h.i.s. .i.s"
00 20 00 61 00 20 00 55 00 73 00 65 00 72 00 45 ". .a. .U.s.e.r.E"
00 78 00 63 00 65 00 70 00 74 00 69 00 6f 00 6e ".x.c.e.p.t.i.o.n"
00 20 00 74 00 65 00 73 00 74 00 00 ff ff ff fe ". .t.e.s.t......"
7f ff ff 0a 00 00 00 45 52 4d 49 3a 5b 4c 6a 61 ".......ERMI:[Lja"
76 61 2e 6c 61 6e 67 2e 53 74 61 63 6b 54 72 61 "va.lang.StackTra"
63 65 45 6c 65 6d 65 6e 74 3b 3a 43 44 33 38 46 "ceElement;:CD38F"
39 39 33 30 45 41 38 41 41 45 43 3a 36 31 30 39 "9930EA8AAEC:6109"
43 35 39 41 32 36 33 36 44 44 38 35 00 00 00 00 "C59A2636DD85...."
00 00 00 04 00 00 00 1f 7f ff ff 02 00 00 00 42 "...............B"
52 4d 49 3a 6a 61 76 61 2e 6c 61 6e 67 2e 53 74 "RMI:java.lang.St"
61 63 6b 54 72 61 63 65 45 6c 65 6d 65 6e 74 3a "ackTraceElement:"
43 44 33 38 46 39 39 33 30 45 41 38 41 41 45 43 "CD38F9930EA8AAEC"
3a 36 31 30 39 43 35 39 41 32 36 33 36 44 44 38 ":6109C59A2636DD8"
35 00 00 00 00 00 00 42 7f ff ff 02 ff ff ff ff "5......B........"
ff ff fe e0 00 00 00 5e fe ff 00 6f 00 72 00 67 ".......^...o.r.g"
00 2e 00 61 00 70 00 61 00 63 00 68 00 65 00 2e "...a.p.a.c.h.e.."
00 67 00 65 00 72 00 6f 00 6e 00 69 00 6d 00 6f ".g.e.r.o.n.i.m.o"
00 2e 00 63 00 6f 00 72 00 62 00 61 00 74 00 65 "...c.o.r.b.a.t.e"
00 73 00 74 00 2e 00 45 00 78 00 63 00 65 00 70 ".s.t...E.x.c.e.p"
00 74 00 69 00 6f 00 6e 00 42 00 65 00 61 00 6e ".t.i.o.n.B.e.a.n"
00 45 00 4a 00 42 00 00 7f ff ff 02 ff ff ff ff ".E.J.B.........."
ff ff fe 70 00 00 00 2c fe ff 00 45 00 78 00 63 "...p...,...E.x.c"
00 65 00 70 00 74 00 69 00 6f 00 6e 00 42 00 65 ".e.p.t.i.o.n.B.e"
00 61 00 6e 00 45 00 4a 00 42 00 2e 00 6a 00 61 ".a.n.E.J.B...j.a"
00 76 00 61 7f ff ff 02 ff ff ff ff ff ff fe 34 ".v.a...........4"
00 00 00 2e fe ff 00 74 00 68 00 72 00 6f 00 77 ".......t.h.r.o.w"
00 5f 00 61 00 5f 00 75 00 73 00 65 00 72 00 5f "..a..u.s.e.r._"
00 65 00 78 00 63 00 65 00 70 00 74 00 69 00 6f ".e.x.c.e.p.t.i.o"
00 6e 00 01 7f ff ff 02 ff ff ff ff ff ff fe c0 ".n.............."
ff ff ff fe 7f ff ff 02 ff ff ff ff ff ff fd e4 "................"
00 00 00 4a fe ff 00 73 00 75 00 6e 00 2e 00 72 "...J...s.u.n...r"
00 65 00 66 00 6c 00 65 00 63 00 74 00 2e 00 4e ".e.f.l.e.c.t...N"
00 61 00 74 00 69 00 76 00 65 00 4d 00 65 00 74 ".a.t.i.v.e.M.e.t"
00 68 00 6f 00 64 00 41 00 63 00 63 00 65 00 73 ".h.o.d.A.c.c.e.s"
00 73 00 6f 00 72 00 49 00 6d 00 70 00 6c ff 0b ".s.o.r.I.m.p.l.."
7f ff ff 02 ff ff ff ff ff ff fd 88 00 00 00 3c "...............<"
fe ff 00 4e 00 61 00 74 00 69 00 76 00 65 00 4d "...N.a.t.i.v.e.M"
00 65 00 74 00 68 00 6f 00 64 00 41 00 63 00 63 ".e.t.h.o.d.A.c.c"
00 65 00 73 00 73 00 6f 00 72 00 49 00 6d 00 70 ".e.s.s.o.r.I.m.p"
00 6c 00 2e 00 6a 00 61 00 76 00 61 7f ff ff 02 ".l...j.a.v.a...."
ff ff ff ff ff ff fd 3c 00 00 00 10 fe ff 00 69 ".......<.......i"
00 6e 00 76 00 6f 00 6b 00 65 00 30 7f ff ff 02 ".n.v.o.k.e.0...."
ff ff ff ff ff ff fd e8 00 00 00 27 ff ff ff ff "...........'...."
ff ff ff 24 ff ff ff ff ff ff ff 78 7f ff ff 02 "...$.......x...."
ff ff ff ff ff ff fc fc 00 00 00 0e fe ff 00 69 "...............i"
00 6e 00 76 00 6f 00 6b 00 65 2f 33 7f ff ff 02 ".n.v.o.k.e/3...."
ff ff ff ff ff ff fd a8 00 00 00 19 7f ff ff 02 "................"
ff ff ff ff ff ff fc cc 00 00 00 52 fe ff 00 73 "...........R...s"
00 75 00 6e 00 2e 00 72 00 65 00 66 00 6c 00 65 ".u.n...r.e.f.l.e"
00 63 00 74 00 2e 00 44 00 65 00 6c 00 65 00 67 ".c.t...D.e.l.e.g"
00 61 00 74 00 69 00 6e 00 67 00 4d 00 65 00 74 ".a.t.i.n.g.M.e.t"
00 68 00 6f 00 64 00 41 00 63 00 63 00 65 00 73 ".h.o.d.A.c.c.e.s"
00 73 00 6f 00 72 00 49 00 6d 00 70 00 6c 67 2e ".s.o.r.I.m.p.lg."
7f ff ff 02 ff ff ff ff ff ff fc 68 00 00 00 44 "...........h...D"
fe ff 00 44 00 65 00 6c 00 65 00 67 00 61 00 74 "...D.e.l.e.g.a.t"
00 69 00 6e 00 67 00 4d 00 65 00 74 00 68 00 6f ".i.n.g.M.e.t.h.o"
00 64 00 41 00 63 00 63 00 65 00 73 00 73 00 6f ".d.A.c.c.e.s.s.o"
00 72 00 49 00 6d 00 70 00 6c 00 2e 00 6a 00 61 ".r.I.m.p.l...j.a"
00 76 00 61 ff ff ff ff ff ff ff 14 7f ff ff 02 ".v.a............"
ff ff ff ff ff ff fc d8 00 00 02 55 7f ff ff 02 "...........U...."
ff ff ff ff ff ff fb fc 00 00 00 32 fe ff 00 6a "...........2...j"
00 61 00 76 00 61 00 2e 00 6c 00 61 00 6e 00 67 ".a.v.a...l.a.n.g"
00 2e 00 72 00 65 00 66 00 6c 00 65 00 63 00 74 "...r.e.f.l.e.c.t"
00 2e 00 4d 00 65 00 74 00 68 00 6f 00 64 00 45 "...M.e.t.h.o.d.E"
7f ff ff 02 ff ff ff ff ff ff fb b8 00 00 00 18 "................"
fe ff 00 4d 00 65 00 74 00 68 00 6f 00 64 00 2e "...M.e.t.h.o.d.."
00 6a 00 61 00 76 00 61 ff ff ff ff ff ff fe 90 ".j.a.v.a........"
7f ff ff 02 ff ff ff ff ff ff fc 54 00 00 04 1c "...........T...."
7f ff ff 02 ff ff ff ff ff ff fb 78 00 00 00 74 "...........x...t"
fe ff 00 6f 00 72 00 67 00 2e 00 67 00 6c 00 61 "...o.r.g...g.l.a"
00 73 00 73 00 66 00 69 00 73 00 68 00 2e 00 65 ".s.s.f.i.s.h...e"
00 6a 00 62 00 2e 00 73 00 65 00 63 00 75 00 72 ".j.b...s.e.c.u.r"
00 69 00 74 00 79 00 2e 00 61 00 70 00 70 00 6c ".i.t.y...a.p.p.l"
00 69 00 63 00 61 00 74 00 69 00 6f 00 6e 00 2e ".i.c.a.t.i.o.n.."
00 45 00 4a 00 42 00 53 00 65 00 63 00 75 00 72 ".E.J.B.S.e.c.u.r"
00 69 00 74 00 79 00 4d 00 61 00 6e 00 61 00 67 ".i.t.y.M.a.n.a.g"
00 65 00 72 7f ff ff 02 ff ff ff ff ff ff fa f4 ".e.r............"
00 00 00 30 fe ff 00 45 00 4a 00 42 00 53 00 65 "...0...E.J.B.S.e"
00 63 00 75 00 72 00 69 00 74 00 79 00 4d 00 61 ".c.u.r.i.t.y.M.a"
00 6e 00 61 00 67 00 65 00 72 00 2e 00 6a 00 61 ".n.a.g.e.r...j.a"
00 76 00 61 7f ff ff 02 ff ff ff ff ff ff fa b4 ".v.a............"
00 00 00 14 fe ff 00 72 00 75 00 6e 00 4d 00 65 ".......r.u.n.M.e"
00 74 00 68 00 6f 00 64 7f ff ff 02 ff ff ff ff ".t.h.o.d........"
ff ff fb 5c 00 00 04 64 ff ff ff ff ff ff ff 04 "...\...d........"
ff ff ff ff ff ff ff 80 ff ff ff ff ff ff fd 70 "...............p"
7f ff ff 02 ff ff ff ff ff ff fb 34 00 00 10 3b "...........4...;"
7f ff ff 02 ff ff ff ff ff ff fa 58 00 00 00 4a "...........X...J"
fe ff 00 63 00 6f 00 6d 00 2e 00 73 00 75 00 6e "...c.o.m...s.u.n"
00 2e 00 65 00 6a 00 62 00 2e 00 63 00 6f 00 6e "...e.j.b...c.o.n"
00 74 00 61 00 69 00 6e 00 65 00 72 00 73 00 2e ".t.a.i.n.e.r.s.."
00 42 00 61 00 73 00 65 00 43 00 6f 00 6e 00 74 ".B.a.s.e.C.o.n.t"
00 61 00 69 00 6e 00 65 00 72 ff ff 7f ff ff 02 ".a.i.n.e.r......"
ff ff ff ff ff ff f9 fc 00 00 00 26 fe ff 00 42 "...........&...B"
00 61 00 73 00 65 00 43 00 6f 00 6e 00 74 00 61 ".a.s.e.C.o.n.t.a"
00 69 00 6e 00 65 00 72 00 2e 00 6a 00 61 00 76 ".i.n.e.r...j.a.v"
00 61 00 74 7f ff ff 02 ff ff ff ff ff ff f9 c4 ".a.t............"
00 00 00 2e fe ff 00 69 00 6e 00 76 00 6f 00 6b ".......i.n.v.o.k"
00 65 00 54 00 61 00 72 00 67 00 65 00 74 00 42 ".e.T.a.r.g.e.t.B"
00 65 00 61 00 6e 00 4d 00 65 00 74 00 68 00 6f ".e.a.n.M.e.t.h.o"
00 64 00 4e 7f ff ff 02 ff ff ff ff ff ff fa 50 ".d.N...........P"
00 00 14 e3 ff ff ff ff ff ff ff 18 ff ff ff ff "................"
ff ff ff 6c 7f ff ff 02 ff ff ff ff ff ff f9 64 "...l...........d"
00 00 00 18 fe ff 00 5f 00 5f 00 69 00 6e 00 74 ".........i.n.t"
00 65 00 72 00 63 00 65 00 70 00 74 7f ff ff 02 ".e.r.c.e.p.t...."
ff ff ff ff ff ff fa 08 00 00 14 cf ff ff ff ff "................"
ff ff fe d0 ff ff ff ff ff ff ff 24 7f ff ff 02 "...........$...."
ff ff ff ff ff ff f9 1c 00 00 00 14 fe ff 00 69 "...............i"
00 6e 00 74 00 65 00 72 00 63 00 65 00 70 00 74 ".n.t.e.r.c.e.p.t"
7f ff ff 02 ff ff ff ff ff ff f9 c4 00 00 00 ce "................"
7f ff ff 02 ff ff ff ff ff ff f8 e8 00 00 00 64 "...............d"
fe ff 00 63 00 6f 00 6d 00 2e 00 73 00 75 00 6e "...c.o.m...s.u.n"
00 2e 00 65 00 6a 00 62 00 2e 00 63 00 6f 00 6e "...e.j.b...c.o.n"
00 74 00 61 00 69 00 6e 00 65 00 72 00 73 00 2e ".t.a.i.n.e.r.s.."
00 45 00 4a 00 42 00 4f 00 62 00 6a 00 65 00 63 ".E.J.B.O.b.j.e.c"
00 74 00 49 00 6e 00 76 00 6f 00 63 00 61 00 74 ".t.I.n.v.o.c.a.t"
00 69 00 6f 00 6e 00 48 00 61 00 6e 00 64 00 6c ".i.o.n.H.a.n.d.l"
00 65 00 72 7f ff ff 02 ff ff ff ff ff ff f8 74 ".e.r...........t"
00 00 00 40 fe ff 00 45 00 4a 00 42 00 4f 00 62 "...@...E.J.B.O.b"
00 6a 00 65 00 63 00 74 00 49 00 6e 00 76 00 6f ".j.e.c.t.I.n.v.o"
00 63 00 61 00 74 00 69 00 6f 00 6e 00 48 00 61 ".c.a.t.i.o.n.H.a"
00 6e 00 64 00 6c 00 65 00 72 00 2e 00 6a 00 61 ".n.d.l.e.r...j.a"
00 76 00 61 ff ff ff ff ff ff fb 24 7f ff ff 02 ".v.a.......$...."
ff ff ff ff ff ff f8 e8 00 00 00 7b ff ff ff ff "...........{...."
ff ff ff 20 ff ff ff ff ff ff ff 8c ff ff ff ff "... ............"
ff ff fa fc 7f ff ff 02 ff ff ff ff ff ff f8 c0 "................"
ff ff ff ff 7f ff ff 02 ff ff ff ff ff ff f7 e4 "................"
00 00 00 14 fe ff 00 24 00 50 00 72 00 6f 00 78 ".......$.P.r.o.x"
00 79 00 32 00 31 00 37 00 00 00 00 ff ff ff ff ".y.2.1.7........"
ff ff f9 84 7f ff ff 02 ff ff ff ff ff ff f8 80 "................"
ff ff ff fe ff ff ff ff ff ff f9 bc ff ff ff ff "................"
ff ff fa 10 ff ff ff ff ff ff fa 54 7f ff ff 02 "...........T...."
ff ff ff ff ff ff f8 58 00 00 00 27 ff ff ff ff ".......X...'...."
ff ff f9 94 ff ff ff ff ff ff f9 e8 ff ff ff ff "................"
ff ff fa 6c 7f ff ff 02 ff ff ff ff ff ff f8 30 "...l...........0"
00 00 00 19 ff ff ff ff ff ff fa 84 ff ff ff ff "................"
ff ff fa e0 ff ff ff ff ff ff fa 44 7f ff ff 02 "...........D...."
ff ff ff ff ff ff f8 08 00 00 02 55 ff ff ff ff "...........U...."
ff ff fb 2c ff ff ff ff ff ff fb 68 ff ff ff ff "...,.......h...."
ff ff fa 1c 7f ff ff 02 ff ff ff ff ff ff f7 e0 "................"
00 00 00 90 7f ff ff 02 ff ff ff ff ff ff f7 04 "................"
00 00 00 6a fe ff 00 63 00 6f 00 6d 00 2e 00 73 "...j...c.o.m...s"
00 75 00 6e 00 2e 00 63 00 6f 00 72 00 62 00 61 ".u.n...c.o.r.b.a"
00 2e 00 65 00 65 00 2e 00 69 00 6d 00 70 00 6c "...e.e...i.m.p.l"
00 2e 00 70 00 72 00 65 00 73 00 65 00 6e 00 74 "...p.r.e.s.e.n.t"
00 61 00 74 00 69 00 6f 00 6e 00 2e 00 72 00 6d ".a.t.i.o.n...r.m"
00 69 00 2e 00 52 00 65 00 66 00 6c 00 65 00 63 ".i...R.e.f.l.e.c"
00 74 00 69 00 76 00 65 00 54 00 69 00 65 ff 04 ".t.i.v.e.T.i.e.."
7f ff ff 02 ff ff ff ff ff ff f6 88 00 00 00 26 "...............&"
fe ff 00 52 00 65 00 66 00 6c 00 65 00 63 00 74 "...R.e.f.l.e.c.t"
00 69 00 76 00 65 00 54 00 69 00 65 00 2e 00 6a ".i.v.e.T.i.e...j"
00 61 00 76 00 61 00 6d 7f ff ff 02 ff ff ff ff ".a.v.a.m........"
ff ff f6 50 00 00 00 22 fe ff 00 64 00 69 00 73 "...P..."...d.i.s"
00 70 00 61 00 74 00 63 00 68 00 54 00 6f 00 4d ".p.a.t.c.h.T.o.M"
00 65 00 74 00 68 00 6f 00 64 00 6f 7f ff ff 02 ".e.t.h.o.d.o...."
ff ff ff ff ff ff f6 e8 00 00 00 ae ff ff ff ff "................"
ff ff ff 04 ff ff ff ff ff ff ff 78 7f ff ff 02 "...........x...."
ff ff ff ff ff ff f5 fc 00 00 00 10 fe ff 00 5f "..............._"
00 69 00 6e 00 76 00 6f 00 6b 00 65 7f ff ff 02 ".i.n.v.o.k.e...."
ff ff ff ff ff ff f6 a8 00 00 02 10 7f ff ff 02 "................"
ff ff ff ff ff ff f5 cc 00 00 00 80 fe ff 00 63 "...............c"
00 6f 00 6d 00 2e 00 73 00 75 00 6e 00 2e 00 63 ".o.m...s.u.n...c"
00 6f 00 72 00 62 00 61 00 2e 00 65 00 65 00 2e ".o.r.b.a...e.e.."
00 69 00 6d 00 70 00 6c 00 2e 00 70 00 72 00 6f ".i.m.p.l...p.r.o"
00 74 00 6f 00 63 00 6f 00 6c 00 2e 00 43 00 6f ".t.o.c.o.l...C.o"
00 72 00 62 00 61 00 53 00 65 00 72 00 76 00 65 ".r.b.a.S.e.r.v.e"
00 72 00 52 00 65 00 71 00 75 00 65 00 73 00 74 ".r.R.e.q.u.e.s.t"
00 44 00 69 00 73 00 70 00 61 00 74 00 63 00 68 ".D.i.s.p.a.t.c.h"
00 65 00 72 00 49 00 6d 00 70 00 6c 7f ff ff 02 ".e.r.I.m.p.l...."
ff ff ff ff ff ff f5 3c 00 00 00 4c fe ff 00 43 ".......<...L...C"
00 6f 00 72 00 62 00 61 00 53 00 65 00 72 00 76 ".o.r.b.a.S.e.r.v"
00 65 00 72 00 52 00 65 00 71 00 75 00 65 00 73 ".e.r.R.e.q.u.e.s"
00 74 00 44 00 69 00 73 00 70 00 61 00 74 00 63 ".t.D.i.s.p.a.t.c"
00 68 00 65 00 72 00 49 00 6d 00 70 00 6c 00 2e ".h.e.r.I.m.p.l.."
00 6a 00 61 00 76 00 61 7f ff ff 02 ff ff ff ff ".j.a.v.a........"
ff ff f4 e0 00 00 00 24 fe ff 00 64 00 69 00 73 ".......$...d.i.s"
00 70 00 61 00 74 00 63 00 68 00 54 00 6f 00 53 ".p.a.t.c.h.T.o.S"
00 65 00 72 00 76 00 61 00 6e 00 74 7f ff ff 02 ".e.r.v.a.n.t...."
ff ff ff ff ff ff f5 78 00 00 00 c7 ff ff ff ff ".......x........"
ff ff fe cc ff ff ff ff ff ff ff 54 7f ff ff 02 "...........T...."
ff ff ff ff ff ff f4 8c 00 00 00 12 fe ff 00 64 "...............d"
00 69 00 73 00 70 00 61 00 74 00 63 00 68 00 62 ".i.s.p.a.t.c.h.b"
7f ff ff 02 ff ff ff ff ff ff f5 34 00 00 06 58 "...........4...X"
7f ff ff 02 ff ff ff ff ff ff f4 58 00 00 00 70 "...........X...p"
fe ff 00 63 00 6f 00 6d 00 2e 00 73 00 75 00 6e "...c.o.m...s.u.n"
00 2e 00 63 00 6f 00 72 00 62 00 61 00 2e 00 65 "...c.o.r.b.a...e"
00 65 00 2e 00 69 00 6d 00 70 00 6c 00 2e 00 70 ".e...i.m.p.l...p"
00 72 00 6f 00 74 00 6f 00 63 00 6f 00 6c 00 2e ".r.o.t.o.c.o.l.."
00 43 00 6f 00 72 00 62 00 61 00 4d 00 65 00 73 ".C.o.r.b.a.M.e.s"
00 73 00 61 00 67 00 65 00 4d 00 65 00 64 00 69 ".s.a.g.e.M.e.d.i"
00 61 00 74 00 6f 00 72 00 49 00 6d 00 70 00 6c ".a.t.o.r.I.m.p.l"
7f ff ff 02 ff ff ff ff ff ff f3 d8 00 00 00 3c "...............<"
fe ff 00 43 00 6f 00 72 00 62 00 61 00 4d 00 65 "...C.o.r.b.a.M.e"
00 73 00 73 00 61 00 67 00 65 00 4d 00 65 00 64 ".s.s.a.g.e.M.e.d"
00 69 00 61 00 74 00 6f 00 72 00 49 00 6d 00 70 ".i.a.t.o.r.I.m.p"
00 6c 00 2e 00 6a 00 61 00 76 00 61 7f ff ff 02 ".l...j.a.v.a...."
ff ff ff ff ff ff f3 8c 00 00 00 2a fe ff 00 68 "...........*...h"
00 61 00 6e 00 64 00 6c 00 65 00 52 00 65 00 71 ".a.n.d.l.e.R.e.q"
00 75 00 65 00 73 00 74 00 52 00 65 00 71 00 75 ".u.e.s.t.R.e.q.u"
00 65 00 73 00 74 ff ff 7f ff ff 02 ff ff ff ff ".e.s.t.........."
ff ff f4 1c 00 00 05 ce ff ff ff ff ff ff fe e4 "................"
ff ff ff ff ff ff ff 5c 7f ff ff 02 ff ff ff ff ".......\........"
ff ff f3 30 00 00 00 1c fe ff 00 68 00 61 00 6e "...0.......h.a.n"
00 64 00 6c 00 65 00 52 00 65 00 71 00 75 00 65 ".d.l.e.R.e.q.u.e"
00 73 00 74 7f ff ff 02 ff ff ff ff ff ff f3 d0 ".s.t............"
00 00 03 de ff ff ff ff ff ff fe 98 ff ff ff ff "................"
ff ff ff 10 7f ff ff 02 ff ff ff ff ff ff f2 e4 "................"
00 00 00 18 fe ff 00 68 00 61 00 6e 00 64 00 6c ".......h.a.n.d.l"
00 65 00 49 00 6e 00 70 00 75 00 74 7f ff ff 02 ".e.I.n.p.u.t...."
ff ff ff ff ff ff f3 88 00 00 00 d6 7f ff ff 02 "................"
ff ff ff ff ff ff f2 ac 00 00 00 82 fe ff 00 63 "...............c"
00 6f 00 6d 00 2e 00 73 00 75 00 6e 00 2e 00 63 ".o.m...s.u.n...c"
00 6f 00 72 00 62 00 61 00 2e 00 65 00 65 00 2e ".o.r.b.a...e.e.."
00 69 00 6d 00 70 00 6c 00 2e 00 70 00 72 00 6f ".i.m.p.l...p.r.o"
00 74 00 6f 00 63 00 6f 00 6c 00 2e 00 67 00 69 ".t.o.c.o.l...g.i"
00 6f 00 70 00 6d 00 73 00 67 00 68 00 65 00 61 ".o.p.m.s.g.h.e.a"
00 64 00 65 00 72 00 73 00 2e 00 52 00 65 00 71 ".d.e.r.s...R.e.q"
00 75 00 65 00 73 00 74 00 4d 00 65 00 73 00 73 ".u.e.s.t.M.e.s.s"
00 61 00 67 00 65 00 5f 00 31 00 5f 00 32 ff ff ".a.g.e..1..2.."
7f ff ff 02 ff ff ff ff ff ff f2 18 00 00 00 30 "...............0"
fe ff 00 52 00 65 00 71 00 75 00 65 00 73 00 74 "...R.e.q.u.e.s.t"
00 4d 00 65 00 73 00 73 00 61 00 67 00 65 00 5f ".M.e.s.s.a.g.e._"
00 31 00 5f 00 32 00 2e 00 6a 00 61 00 76 00 61 ".1._.2...j.a.v.a"
7f ff ff 02 ff ff ff ff ff ff f1 d8 00 00 00 12 "................"
fe ff 00 63 00 61 00 6c 00 6c 00 62 00 61 00 63 "...c.a.l.l.b.a.c"
00 6b 00 72 7f ff ff 02 ff ff ff ff ff ff f2 80 ".k.r............"
00 00 02 e6 ff ff ff ff ff ff fd 48 ff ff ff ff "...........H...."
ff ff fd c0 ff ff ff ff ff ff fe 60 7f ff ff 02 "...........`...."
ff ff ff ff ff ff f2 58 00 00 02 1b ff ff ff ff ".......X........"
ff ff fd 20 ff ff ff ff ff ff fd 98 ff ff ff ff "... ............"
ff ff fc dc 7f ff ff 02 ff ff ff ff ff ff f2 30 "...............0"
00 00 01 57 7f ff ff 02 ff ff ff ff ff ff f1 54 "...W...........T"
00 00 00 7c fe ff 00 63 00 6f 00 6d 00 2e 00 73 "...|...c.o.m...s"
00 75 00 6e 00 2e 00 63 00 6f 00 72 00 62 00 61 ".u.n...c.o.r.b.a"
00 2e 00 65 00 65 00 2e 00 69 00 6d 00 70 00 6c "...e.e...i.m.p.l"
00 2e 00 74 00 72 00 61 00 6e 00 73 00 70 00 6f "...t.r.a.n.s.p.o"
00 72 00 74 00 2e 00 53 00 6f 00 63 00 6b 00 65 ".r.t...S.o.c.k.e"
00 74 00 4f 00 72 00 43 00 68 00 61 00 6e 00 6e ".t.O.r.C.h.a.n.n"
00 65 00 6c 00 43 00 6f 00 6e 00 6e 00 65 00 63 ".e.l.C.o.n.n.e.c"
00 74 00 69 00 6f 00 6e 00 49 00 6d 00 70 00 6c ".t.i.o.n.I.m.p.l"
7f ff ff 02 ff ff ff ff ff ff f0 c8 00 00 00 46 "...............F"
fe ff 00 53 00 6f 00 63 00 6b 00 65 00 74 00 4f "...S.o.c.k.e.t.O"
00 72 00 43 00 68 00 61 00 6e 00 6e 00 65 00 6c ".r.C.h.a.n.n.e.l"
00 43 00 6f 00 6e 00 6e 00 65 00 63 00 74 00 69 ".C.o.n.n.e.c.t.i"
00 6f 00 6e 00 49 00 6d 00 70 00 6c 00 2e 00 6a ".o.n.I.m.p.l...j"
00 61 00 76 00 61 ff ff 7f ff ff 02 ff ff ff ff ".a.v.a.........."
ff ff f0 70 00 00 00 0a fe ff 00 72 00 65 00 61 "...p.......r.e.a"
00 64 00 63 7f ff ff 02 ff ff ff ff ff ff f1 20 ".d.c........... "
00 00 00 70 7f ff ff 02 ff ff ff ff ff ff f0 44 "...p...........D"
00 00 00 62 fe ff 00 63 00 6f 00 6d 00 2e 00 73 "...b...c.o.m...s"
00 75 00 6e 00 2e 00 63 00 6f 00 72 00 62 00 61 ".u.n...c.o.r.b.a"
00 2e 00 65 00 65 00 2e 00 69 00 6d 00 70 00 6c "...e.e...i.m.p.l"
00 2e 00 74 00 72 00 61 00 6e 00 73 00 70 00 6f "...t.r.a.n.s.p.o"
00 72 00 74 00 2e 00 52 00 65 00 61 00 64 00 65 ".r.t...R.e.a.d.e"
00 72 00 54 00 68 00 72 00 65 00 61 00 64 00 49 ".r.T.h.r.e.a.d.I"
00 6d 00 70 00 6c 00 72 7f ff ff 02 ff ff ff ff ".m.p.l.r........"
ff ff ef d0 00 00 00 2c fe ff 00 52 00 65 00 61 ".......,...R.e.a"
00 64 00 65 00 72 00 54 00 68 00 72 00 65 00 61 ".d.e.r.T.h.r.e.a"
00 64 00 49 00 6d 00 70 00 6c 00 2e 00 6a 00 61 ".d.I.m.p.l...j.a"
00 76 00 61 7f ff ff 02 ff ff ff ff ff ff ef 94 ".v.a............"
00 00 00 0e fe ff 00 64 00 6f 00 57 00 6f 00 72 ".......d.o.W.o.r"
00 6b 00 65 7f ff ff 02 ff ff ff ff ff ff f0 40 ".k.e...........@"
00 00 01 f1 7f ff ff 02 ff ff ff ff ff ff ef 64 "...............d"
00 00 00 8a fe ff 00 63 00 6f 00 6d 00 2e 00 73 ".......c.o.m...s"
00 75 00 6e 00 2e 00 63 00 6f 00 72 00 62 00 61 ".u.n...c.o.r.b.a"
00 2e 00 65 00 65 00 2e 00 69 00 6d 00 70 00 6c "...e.e...i.m.p.l"
00 2e 00 6f 00 72 00 62 00 75 00 74 00 69 00 6c "...o.r.b.u.t.i.l"
00 2e 00 74 00 68 00 72 00 65 00 61 00 64 00 70 "...t.h.r.e.a.d.p"
00 6f 00 6f 00 6c 00 2e 00 54 00 68 00 72 00 65 ".o.o.l...T.h.r.e"
00 61 00 64 00 50 00 6f 00 6f 00 6c 00 49 00 6d ".a.d.P.o.o.l.I.m"
00 70 00 6c 00 24 00 57 00 6f 00 72 00 6b 00 65 ".p.l.$.W.o.r.k.e"
00 72 00 54 00 68 00 72 00 65 00 61 00 64 ff 02 ".r.T.h.r.e.a.d.."
7f ff ff 02 ff ff ff ff ff ff ee c8 00 00 00 28 "...............("
fe ff 00 54 00 68 00 72 00 65 00 61 00 64 00 50 "...T.h.r.e.a.d.P"
00 6f 00 6f 00 6c 00 49 00 6d 00 70 00 6c 00 2e ".o.o.l.I.m.p.l.."
00 6a 00 61 00 76 00 61 7f ff ff 02 ff ff ff ff ".j.a.v.a........"
ff ff ee 90 00 00 00 18 fe ff 00 70 00 65 00 72 "...........p.e.r"
00 66 00 6f 00 72 00 6d 00 57 00 6f 00 72 00 6b ".f.o.r.m.W.o.r.k"
7f ff ff 02 ff ff ff ff ff ff ef 34 00 00 02 1c "...........4...."
ff ff ff ff ff ff fe f0 ff ff ff ff ff ff ff 84 "................"
7f ff ff 02 ff ff ff ff ff ff ee 48 00 00 00 08 "...........H...."
fe ff 00 72 00 75 00 6e ff ff ff fe 00 00 00 08 "...r.u.n........"
ff ff ff ff ff ff ee 28 ff ff ff ff ".......(...."

From the dumped GIOP stream, we can see this GIOP stream version is 1.2, and this is a custom marshal of RMI valuetype.

We expect chunked encoding for the custom marshal, however, Glassfish sent us the GIOP stream without chunking for implicit super class valuetype.



 Comments   
Comment by Harshad Vilekar [ 15/Dec/11 ]

3_1_2-exclude: Not enough time to analyze/fix in 3.1.2.





[GLASSFISH-17222] Remote EJB / SerialInitContextFactory "Cannot modify frozen instance for org.omg.CORBA.portable.InputStream" Created: 22/Aug/11  Updated: 02/Jul/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1, 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aldrinleal Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win32, JDK 6, Windows 7


Tags: 3_1_2-exclude, ejb, orb, remoting

 Description   

I get this exception when I lookup an object deployed as an EAR containing an EJB jar:

20/08/2011 05:38:15 org.glassfish.enterprise.iiop.impl.GlassFishORBManager initORB
GRAVE: enterprise_util.excep_in_createorb
java.lang.IllegalStateException: Cannot modify frozen instance for org.omg.CORBA.portable.InputStream
at org.glassfish.gmbal.typelib.DeclarationFactory$EvaluatedClassDeclarationImpl.checkFrozen(DeclarationFactory.java:380)
at org.glassfish.gmbal.typelib.DeclarationFactory$EvaluatedClassDeclarationImpl.inheritance(DeclarationFactory.java:390)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:716)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:711)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:709)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:707)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:711)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:709)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:707)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator.getEvaluatedType(TypeEvaluator.java:318)
at org.glassfish.gmbal.impl.ManagedObjectManagerImpl.constructMBean(ManagedObjectManagerImpl.java:659)
at org.glassfish.gmbal.impl.MBeanTree.setRoot(MBeanTree.java:98)
at org.glassfish.gmbal.impl.ManagedObjectManagerImpl.createRoot(ManagedObjectManagerImpl.java:451)
at com.sun.corba.ee.spi.orb.ORB.createORBManagedObjectManager(ORB.java:790)
at com.sun.corba.ee.impl.orb.ORBImpl.initManagedObjectManager(ORBImpl.java:401)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:581)
at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:704)
at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:691)
at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:581)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:152)
at com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:365)
at com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(SerialContext.java:372)
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:402)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:347)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:504)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at us.fiveguns.rokkitdelivery.service.impl.ejb.EjbServiceFactory.getService(EjbServiceFactory.java:183)
at us.fiveguns.rokkitdelivery.service.impl.ejb.EjbServiceFactory.getSecurityService(EjbServiceFactory.java:115)
at us.fiveguns.rokkitdelivery.admin.jsf.controllers.SecurityController.logIn(SecurityController.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)

As first, it seems fine - It works when using In-VM, however this happens when remoting the connection. HEre is the code for fetching the Interface:

Properties props = new Properties();

props.setProperty("java.naming.factory.initial",
"com.sun.enterprise.naming.SerialInitContextFactory");

props.setProperty("java.naming.factory.url.pkgs",
"com.sun.enterprise.naming");

props.setProperty("java.naming.factory.state",
"com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

//props.setProperty("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");

// optional. Defaults to localhost. Only needed if web server is running
// on a different host than the appserver
props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");

// optional. Defaults to 3700. Only needed if target orb port is not
// 3700.
props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");

try

{ this.context = new InitialContext(props); }

catch (Exception exc)

{ throw new RuntimeException(exc); }

 Comments   
Comment by sbahloul79 [ 02/Jul/13 ]

I encountered this error because of a parent class loading issue on Jetty, that has been fixed with the settings specified in http://docs.codehaus.org/display/JETTY/Remote+Glassfish+EJBs+from+Jetty (parentLoaderPriority)





[GLASSFISH-16492] NamingException when calling an EJB from one standalone instance to another Created: 28/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b43, 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: brzhk Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
Ubuntu 10.10
Glassfish 3.1 b43


Attachments: File hades-testcase.tar.bz2    
Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

(testcase included, with two maven projects : hades creates an EAR & the EJB client jar. should be created with mvn install. install on instance A check the IIOP port. hades-client is a simple war which depends on the hades ejb client jar. open CallServlet and change the IIOP port to call accordingly. run with maven package. install on instance B. Run /CallServlet.)

I tried spawning two standalone instances in my admin console, i deployed an ejb-app on my instance A and a client on my instance B. Whereas it worked flawlessly when both of these applications were installed on the virtual server 'server', now the call fails with this error:

javax.naming.NamingException: Lookup failed for
'java:global/hades/auth-0.0.1-SNAPSHOT/CustomerAuthEjb!com.hypsoma.hades.auth.CustomerAuthEjbRemote'
in SerialContext[myEnv=

{org.omg.CORBA.ORBInitialPort=3700, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, org.omg.CORBA.ORBInitialHost=127.0.0.1, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.hypsoma.hades.auth.CustomerAuthEjbRemote [Root exception is org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:409)
at javax.naming.InitialContext.lookup(InitialContext.java:409)
at com.hypsoma.test.CallServlet.doGet(CallServlet.java:47)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:636)
Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.hypsoma.hades.auth.CustomerAuthEjbRemote [Root exception is org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
... 31 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy130.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:86)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
at com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
at com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:574)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422)
... 35 more
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)



 Comments   
Comment by kumarjayanti [ 29/Apr/11 ]

I believe you are running into this issue. Can you check :

http://download.oracle.com/docs/cd/E19226-01/820-7688/gjktd/index.html

Comment by marina vatkina [ 02/May/11 ]

Seems like an ORB issue

Comment by Ken Cavanaugh [ 18/May/11 ]

Can't fix in 3.1.1.





[GLASSFISH-16481] Dynamically-assigned IP addresses for cloud instances require changes to app client bootstrapping for remote RMI-IIOP access Created: 27/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb, rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GF 3.2 will support clouds with both statically and dynamically (DHCP) assigned IP addresses. This has
an impact on supporting app clients that access EJBs remotely and to IIOP FOLB.

First, a couple of points about the ORB:

  • The ORB normally caches and re-uses TCP/IP connections aggressively, and holds TCP connections open for a long time.
  • Stateful EJBs have their current state on a single instance, and for efficiency we normally want each request to go to the same instance.
    o When a failure occurs, IIOP failover causes all EJBs that were accessed from the failed instance to failover to the same instance ("Sticky failover").

Typically a cloud-based cluster will have a load balancer at a well-known address for handling HTTP traffic.
The instances in the cloud may or may not be accessible over the public internet (if not, the load balancer sits
in some kind of DMZ so at least an address on the LB is publicly accessible). We have the following possible scenarios:

1. Only the LB is publicly accessible.
2. LB and instances are publicly accessible, static cluster.
3. LB and instances are publicly accessible, dynamic cluster.

Case 1 is discussed in RFE 16480.

Case 2 is probably no different than supporting IIOP FOLB in GF 3.1, so it needs no further discussion.

Case 3 is interesting, because it creates a bootstrapping problem. Currently IIOP FOLB assumes that there are
at least 2 fixed addresses of instances in the cluster which can be used to bootstrap into full FOLB operation.
This is not the case for the dynamic cluster, where an app client may find that all of the instance addresses have
been re-assigned every time it attempt to contact the cluster. The only available fixed, known address in this case
is that of the load balancer (which itself may will use DNS tricks to make more than one IP address available, both
for load balancing and high availability). So IIOP FOLB must make use of the LB address in this case.

While perhaps a suitable LB might be persuaded to support some sort of request that gives the client ORB the
information that it needs, I think Tim's suggestion of a small web listener is a better idea. Here something
in each GF 3.2 instance is listing to a URL like

http(s)://host:8080/__ORBS

which would respond to a GET request with a list of instance addresses in the cluster (and perhaps other information?).
This might be formatted using JSON for convenient processing.

It's not clear whether security is required here. If it is, it would add significant complexity and require integration with
the Java SE security facilities for managing a password or certificate.

I'm not sure how best to implement this in GF; I'm sure someone familiar with the web programming side of things could
point out how to implement this rather easily.

These issues are also summarized at the Dynamic IP address concerns page.






[GLASSFISH-16480] App client using RMI-IIOP needs to work in cloud without public IP addresses Created: 27/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb, rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GF 3.2 will support clouds with both statically and dynamically (DHCP) assigned IP addresses. This has
an impact on supporting app clients that access EJBs remotely and to IIOP FOLB.

First, a couple of points about the ORB:

  • The ORB normally caches and re-uses TCP/IP connections aggressively, and holds TCP connections open for a long time.
  • Stateful EJBs have their current state on a single instance, and for efficiency we normally want each request to go to the same instance.
    o When a failure occurs, IIOP failover causes all EJBs that were accessed from the failed instance to failover to the same instance ("Sticky failover").

Typically a cloud-based cluster will have a load balancer at a well-known address for handling HTTP traffic.
The instances in the cloud may or may not be accessible over the public internet (if not, the load balancer sits
in some kind of DMZ so at least an address on the LB is publicly accessible). We have the following possible scenarios:

1. Only the LB is publicly accessible.
2. LB and instances are publicly accessible, static cluster.
3. LB and instances are publicly accessible, dynamic cluster.

In case 1, we have no choice but to direct IIOP traffic to the LB, assuming that the LB allows this.
If the application only uses stateless EJBs, we just run the ORB in a no-connection cache/connection per request mode
(we delivered this feature for NTT west around 5 years ago in GF 2.1.1). This allows the LB to make load balancing
decisions based on just a new TCP connection, and works reasonably well.

If the application requires stateful EJBs in case 1, we currently have no solution. I think a solution would require that the
LB somehow be aware of a sort of session affinity, where each request would be load balanced to the instance currently
containing the session for the EJB instance. A request that establishes a new session (currently that is the request
that a new InitialContext call sends) could be load balanced to any instance in the cluster. This would be very
similar to how the current IIOP LB mechanism works.

If the LB does not support IIOP, it would probably be necessary to use some sort of HTTP tunneling of IIOP requests.
This has been done many times in many products over the years (including in the circa 1995 Sun JOE ORB, probably the
first Java ORB written), but we have never supported it in the JDK/SJSAS/GF ORBs (which started in 1997). There is no
standard for tunneling IIOP over HTTP, but we could invent something proprietary to solve the problem if necessary.

Case 2 is probably no different than supporting IIOP FOLB in GF 3.1, so it needs no further discussion.

Case 3 creates a bootstrapping issue considered in another RFE.

These issues are also summarized at the Dynamic IP address concerns page.






[GLASSFISH-16737] ClassCopierOrdinaryImpl call readResolve but It hasn't replace the original instance in oldToNew map. Created: 25/May/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chunlinyao Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04 (i386, Version: 2.6.32-31-generic-pae)
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)


Tags: 3_1_1, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I found these code from ClassCopierBase.java

/** Make the actual copy of source, using oldToNew to preserve aliasing.

  • This first checks to see whether source has been previously copied.
  • If so, the value obtained from oldToNew is returned. Otherwise,
  • <ol>
  • <li>createCopy( source ) is called to create a new copy of source.
  • <li>The new copy is placed in oldToNew with source as its key.
  • <li>doCopy is called to complete the copy.
  • <ol>
  • <p>This split into two phases isolates all subclasses from the need to
  • update oldToNew. It accommodates simple cases (arrays of primitives
  • for example) that only need to define createCopy, as well as more complex
  • case (general objects) that must first create the copy, update oldToNew,
  • and then do the copy, as otherwise self-references would cause
  • infinite recursion.
    */
    public final Object copy( Map oldToNew,
    Object source ) throws ReflectiveCopyException { return copy( oldToNew, source, false ) ; }

public final Object copy( Map oldToNew,
Object source, boolean debug ) throws ReflectiveCopyException
{
Object result = oldToNew.get( source ) ;
if (result == null)

{ result = createCopy( source, debug ) ; oldToNew.put( source, result ) ; result = doCopy( oldToNew, source, result, debug ) ; }

return result ;
}

The doCopy method may return another instance other than the one in arguments.
ClassCopierOrdinaryImpl#doCopy will call readResolve method and return the result.
Details of readResolve method can be found at
http://download.oracle.com/javase/1.3/docs/guide/serialization/spec/input.doc6.html

But neither ClassCopierOrdinaryImpl nor ClassCopierBase put the instance returned by
readResolve method to oldToNew map, If the source have two field point to same object.
If the Class of field have a readResolve method return other instance.After copy the
two field have different object,maybe they are not equals.

If I have a class Foo and Bar.
final class Foo {
Bar old;
Bar new;
}

final class Bar{
private final static Bar instance = new Bar();
private Bar(){}

public static Bar getInstance()

{ return instance; }
private Object readResolve(){ return instance; }

}

main() {
Foo foo = new Foo();
foo.old = Bar.getInstance();
foo.new = Bar.getInstance();
foo.old == foo.new //true
...After copy
copiedfoo.new == copiedfoo.old //false
}






[GLASSFISH-17557] Odd deserialization fail Created: 02/Nov/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ylemoigne Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, oracle jdk 1.6.0_29 (all 64bit)


Issue Links:
Related
is related to GLASSFISH-16164 eclipselink.weaving breaks marshallin... Open
Tags: 3_1_2-exclude

 Description   

I have objects loaded from jpa provider (hibernate). All entity implements java.io.Serializable. Transferring different instance of a same class, some instance transfert well, other not. The behavior is stable (it's always the same instances which fail).

The error occur when reading the feed on the client side. If I make the "problematic" instance transient, all go well.
The client classpath is mostly the same than the server one (using maven and gs-client 3.1.1, with the following exclusion :
<exclusion>
<artifactId>eclipselink-wrapper</artifactId>
<groupId>org.glassfish.persistence</groupId>
</exclusion>
<exclusion>
<artifactId>javax.persistence</artifactId>
<groupId>org.eclipse.persistence</groupId>
</exclusion>
<exclusion>
<artifactId>tools</artifactId>
<groupId>com.sun</groupId>
</exclusion>

Suspecting a pure and simple serialization problem on my side, In the EJB, before returning the object, I added this code :
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("c:/dev/response.ser"));
oos.writeObject(response);

And in client project, I tried to read the stream, all is OK in this mode. That's why I suspect now the orb component.
Sadly, I can't deliver you a test case, app code is confidential and I failed to reproduce the "bug" in an independant project.

Here is the full trace client side (no problem on server side) :
2 nov. 2011 04:07:41 com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
ATTENTION: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream
org.omg.CORBA.MARSHAL: ATTENTION: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2090)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.ArrayList.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.HashMap.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at fr.lactalis.gmp._JEEMessageManagerRemote_Remote_DynamicStub.processMessage(fr/lactalis/gmp/_JEEMessageManagerRemote_Remote_DynamicStub.java)
at fr.lactalis.gmp._JEEMessageManagerRemote_Wrapper.processMessage(fr/lactalis/gmp/_JEEMessageManagerRemote_Wrapper.java)
at fr.lactalis.gmp.swing.ui.JEEMessageTransmitter.transmitMessage(JEEMessageTransmitter.java:64)
at fr.lactalis.framework.comm.impl.MessageManagerImpl.doSendMessage(MessageManagerImpl.java:96)
at fr.lactalis.framework.comm.impl.MessageManagerImpl$1.run(MessageManagerImpl.java:55)
Caused by: java.io.OptionalDataException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.HashMap.readObject(Unknown Source)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 110 more
Caused by: org.omg.CORBA.MARSHAL: FIN: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 122 more
Exception, TODOl: manage callbackException
javax.ejb.EJBException: java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: ATTENTION: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at fr.lactalis.gmp._JEEMessageManagerRemote_Wrapper.processMessage(fr/lactalis/gmp/_JEEMessageManagerRemote_Wrapper.java)
at fr.lactalis.gmp.swing.ui.JEEMessageTransmitter.transmitMessage(JEEMessageTransmitter.java:64)
at fr.lactalis.framework.comm.impl.MessageManagerImpl.doSendMessage(MessageManagerImpl.java:96)
at fr.lactalis.framework.comm.impl.MessageManagerImpl$1.run(MessageManagerImpl.java:55)
Caused by: java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: ATTENTION: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:267)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at fr.lactalis.gmp._JEEMessageManagerRemote_Remote_DynamicStub.processMessage(fr/lactalis/gmp/_JEEMessageManagerRemote_Remote_DynamicStub.java)
... 4 more
Caused by: org.omg.CORBA.MARSHAL: ATTENTION: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2090)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.ArrayList.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.HashMap.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
... 7 more
Caused by: java.io.OptionalDataException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.HashMap.readObject(Unknown Source)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 110 more
Caused by: org.omg.CORBA.MARSHAL: FIN: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 122 more

I can't deliver code, but I'm ready to make all the needed testing and report to help to solve this. Just ask for what you need.
Thanks.



 Comments   
Comment by Harshad Vilekar [ 03/Nov/11 ]

Please see the suggested workaround for GLASSFISH-16164. Does disabling hibernate weaving has any effect on your use case ?

Comment by ylemoigne [ 03/Nov/11 ]

I don't understand, on GLASSFISH-16164, it is the eclipselink.weaving which is disabled, not hibernate one :/

I saw this bug while I was searching solution on my serialization problem and already added the workaround to my persistence.xml

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
version="2.0">
<persistence-unit name="default" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>jdbc/gmpcft003v15</jta-data-source>
<non-jta-data-source>jdbc/gmpcft003v15</non-jta-data-source>

<class>...</class>

<properties>
<!-- http://java.net/jira/browse/GLASSFISH-16164 -->
<property name="eclipselink.weaving" value="false"/>
<property name="eclipselink.weaving.fetchgroups" value="false"/>

<!-- We are using the @any annotation -->
<property name="hibernate.ejb.metamodel.generation" value="disabled"/>

<property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect" />

<property name="hibernate.show_sql" value="false" />
<property name="hibernate.format_sql" value="false" />

<property name="hibernate.max_fetch_depth" value="1" />
<property name="hibernate.connection.autocommit" value="false" />
<property name="hibernate.jdbc.batch_versioned_data" value="true" />
<property name="hibernate.jdbc.use_streams_for_binary"
value="true" />
<property name="hibernate.cache.use_second_level_cache" value="false"/>
<property name="hibernate.query.substitutions" value="yes 'Y', no 'N'" />
</properties>
</persistence-unit>
</persistence>

Doesn't change anything





[GLASSFISH-17535] CORBA throws NullPointerException Created: 31/Oct/11  Updated: 10/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1, 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dennis Schwarz Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 64bit (Lucid Lynx), 2.6.32-22-generic, Glassfish 3.1.1, Netbeans 7.0.1, jdk1.6.0_25


Attachments: Zip Archive GF_CORBA_Bug.zip    
Tags: 3_1_2-exclude, corba, nullpointerexception

 Description   

When invoking a method of an remote EJB with a parameter that extends a base class, and this extended class is located in the client, I get a NullPointerException from CORBA.
Invoking this method with the not extended base class works fine.
I expected the extended class to be casted to the base class or throwing a ClassNotFoundException, but not a NullPointerException.

WARNING: IOP00010002: Unknown user exception thrown by the server - exception: java.lang.NullPointerException; message: null
org.omg.CORBA.UNKNOWN: WARNING: IOP00010002: Unknown user exception thrown by the server - exception: java.lang.NullPointerException; message: null vmcid: OMG minor code: 2 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
....
Caused by: java.lang.NullPointerException
at com.sun.corba.ee.impl.orbutil.ClassInfoCache$ClassInfo.<init>(ClassInfoCache.java:156)
at com.sun.corba.ee.impl.orbutil.ClassInfoCache.get(ClassInfoCache.java:281)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1097)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)

Full stacktrace is available here:
http://java.net/projects/glassfish/lists/users/archive/2011-10/message/460

As attachment three example projects to reproduce this bug.



 Comments   
Comment by Tom Mueller [ 31/Oct/11 ]

Moving to the "orb" category.

Comment by chrispy [ 24/Sep/12 ]

This strange bug still exists in GF 3.1.2.2
I tested it with EcliseLink and OpenJPA (with static weaving).
So remote EJB3.1 with JPA2 is not working correctly...
Is there a plan to fix this issue in the next GF-Release?

Comment by novy154 [ 10/Sep/14 ]

Does anyone have fix for this? I'm using glassfish 3.1.2.2, no chances for upgrade unfortunately - and of course this bug is still present...





[GLASSFISH-17471] IIOP Listener pages can add SSL section to unencrypted orb listener causing another problem Created: 25/Oct/11  Updated: 12/Dec/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: james143 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL5 x64, RHEL6 x64


Tags: 3_1_2-exclude, admin-gui, corba, iiop, orb

 Description   

When using the admin console if you view the SSL page for an unencrypted orb-listener and then save changes to something (even a change at the ORB level) then the following gets added to the XML for the <iiop-listener ...>
<ssl classname="com.sun...GlassfishSSLImpl" cert-nickname=""></ssl>

This does not effect the unencrypted nature of the iiop-listener but does seem to turn on required client authentication for the listener.
The net effect of this is that unauthenticated connections to the listener get rejected with a CORBA_NO_PERMISSION exception.



 Comments   
Comment by Anissa Lam [ 25/Oct/11 ]

console is saving as user instructed. Please include the entire <iiop-listener> element also to confirm that "security-enabled" is not turned on.
Transfer to orb fo evaluation on why this should affect authentication.

Comment by james143 [ 25/Oct/11 ]

"security-enabled" is not turned on, it's not present in : <iiop-listener id="orb-listener-1" port="3700" address="qa-host.test.org">

Comment by Harshad Vilekar [ 02/Nov/11 ]

If "security-enabled" is not turned on for "orb-listener-1", then <ssl> element need not be present for orb-listener-1. Transfer to admin-gui for further analysis.

Comment by Anissa Lam [ 04/Nov/11 ]

User does a 'save' thus the <ssl> is added. GUI is doing the correct thing.
Whether <ssl> element exists or not should not change the authentication behavior.
User also confirmed that 'security-enabled' is not present, which means it has the default value, "false".

Transfer to "orb" as why equired client authentication for the listener when security-enable is false.
And why "The net effect of this is that unauthenticated connections to the listener get rejected with a CORBA_NO_PERMISSION exception."

Comment by boernd [ 12/Dec/13 ]

Hi,

I can actually reproduce this issue (gf 3.1.2.2) without doing any save operations in the DAS GUI.

Scenario:

  • Create a testinstance: ./asadmin create-instance --node localhost-domain1 testing
  • After creation the IIOP configuration looks like this:

<config name="testing-config">
[...]
<iiop-listener id="orb-listener-1" port="$

{IIOP_LISTENER_PORT}" address="0.0.0.0"></iiop-listener>

- Open the DAS GUI and browse to Configurations/testing-config/ORB/IIOP Listeners/orb-listener-1
- Click on the SSL tab. This click triggers changes to the domain.xml. Afterwards the iiop-listener looks like this

<iiop-listener id="orb-listener-1" port="${IIOP_LISTENER_PORT}

" address="0.0.0.0">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname=""></ssl>
</iiop-listener>

This change happens without any feedback in the GUI and after the restart you are confronted with CORBA_NO_PERMISSION exceptions and have no clue whats going on...





[GLASSFISH-17356] Problems with remote glassfish corbaname Created: 27/Sep/11  Updated: 28/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: orair Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days
Environment:

Linux ubuntu


Issue Links:
Related
is related to GLASSFISH-18020 [UB]Errors in JNDI chapter of Applica... Resolved
Tags: 3_1_2-exclude

 Description   

I have problems to configure a project WAR inside a glassfish instance A to access remotely an EJB inside instance B.

Logging results in:
Remote JNDI name used for lookup is 'corbaname:iiop:1.2@127.0.0.1:3700#java:global/Portal-ear/ServiceEJBImpl__3_x_Internal_RemoteBusinessHome__' [Root exception is org.omg.CORBA.BAD_PARAM: BOM: IOP00100009: string_to_object conversion failed due to bad schema specific part in name java:global/Portal-ear/ServiceEJBImpl__3_x_Internal_RemoteBusinessHome__ vmcid: SUN minor code: 9 completed: No]

I found many issues related such as GLASSFISH-4880 and GLASSFISH-14704.

In GLASSFISH-4880 the bug was "fixed" but the solution just reference a Jboss similar solution: http://objectmix.com/java/70356-jndi-jboss-127-0-0-1-1098-problem.html#post259802
Someone could please be more specific on this issue?
I really think just mentioning a Jboss solution is not good at all.

Furthermore, the logging generated by these kind of error do not help too much for users neither for developers as we can verify in GLASSFISH-14704.

Additionally, actual documentation is poor and has many errors.
In http://download.oracle.com/docs/cd/E19798-01/821-1752/beanv/index.html and http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beans.html the examples presents typo erros resulting in bad-formatted XML.

In reference http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html, the doc looks like a bit clearer. Otherwise, in section "What is the relationship between @EJB and ejb-ref/ejb-local-ref?" it gives hints about the relationship between @EJB and ejb-ref but lets unclear about the relationship with jndi-name inside glassfish-web.xml.

What is preferred to make remote invocation? lookup name inside web.xml or jndi-name inside glassfish-web.xml? What are the differences between these strategies?
I couldn't make work any of these alternatives. It worked for me just specifying mapped-name inside web.xml and referencing the IP 127.0.0.1.

Could someone add comments about which kind of network issues may arise from these configuration?
Could someone at least improve logging to make possible to identify the bugs in each specific environment?



 Comments   
Comment by dk123 [ 28/Feb/12 ]

We are facing the same issue. The details can be found here: http://www.java.net/forum/topic/glassfish/glassfish/unable-do-remote-ejb-access-different-host?force=133.

we also tried using the front-end back-end test cases from Glassfish bug: http://java.net/jira/browse/GLASSFISH-15523. We are getting the same exception.

Can someone pls. let us know if there is a work around for this issue.





[GLASSFISH-20799] Threads stuck in ClassCopierFactoryPipelineImpl Created: 06/Sep/13  Updated: 03/Feb/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: boernd Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 5.8
java version "1.7.0_25"



 Description   

On one of our environments GlassFish becomes unresponsive with threads stuck in the following WAIT state:

"http-thread-pool-8080(1)" - Thread t@238
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <5def7775> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
    at com.sun.corba.ee.impl.orbutil.copyobject.ClassCopierFactoryPipelineImpl.getClassCopier(ClassCopierFactoryPipelineImpl.java:276)

No thread in the stacktrace seems to hold the lock or is in a runnable state, all threads are waiting to acquire the lock.

We tried to debug the issue adding system outs to the ClassCopierFactoryPipelineImpl class. It shows the following error scenario:

[#|2013-09-06T11:02:49.473+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=243;_ThreadName=Thread-2;|###LOCKISSUE: Acquired read lock for thread 243|#]

[#|2013-09-06T11:02:49.474+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=243;_ThreadName=Thread-2;|###LOCKISSUE: Released read lock for thread 243|#]

[#|2013-09-06T11:02:49.474+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=243;_ThreadName=Thread-2;|###LOCKISSUE: Acquired read lock for thread 243|#]

[#|2013-09-06T11:02:49.474+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=243;_ThreadName=Thread-2;|###LOCKISSUE: Trying to acquire write lock for thread: 243|#]

[#|2013-09-06T11:02:49.877+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=211;_ThreadName=Thread-2;|###LOCKISSUE: Acquired read lock for thread 211|#]

[#|2013-09-06T11:02:49.877+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=211;_ThreadName=Thread-2;|###LOCKISSUE: Released read lock for thread 211|#]

[#|2013-09-06T11:02:49.878+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=211;_ThreadName=Thread-2;|###LOCKISSUE: Acquired read lock for thread 211|#]

[#|2013-09-06T11:02:49.878+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=211;_ThreadName=Thread-2;|###LOCKISSUE: Released read lock for thread 211|#]

The write lock for thread 243 never comes back. After some time also the read lock request get stuck and the server becomes unresponsive.



 Comments   
Comment by tl_shark [ 29/Jan/14 ]

Hello,

we have the same problem. After searching for a cause for several days, we have the idea that the cause might be the second cpu installed some weeks ago. Could you tell me, if you still have this problem and if you have several cpu's.

At the moment we try to solve the problem by locking the glassfish process to just one of the cpu's.

Comment by boernd [ 03/Feb/14 ]

Hi,

at the moment we are only experiencing this issue on one of our test environments which is a KVM based virtualization. One test server has serveral CPUs assigned. So maybe the issue is KVM related and not a GF issue at all.

We "fixed" the issue by making the getClassCopier method in the ClassCopierFactoryPipelineImpl class synchronized and removing the ReentrantReadWriteLock stuff. This has probably a big performance impact. But we are using the environment just for functional testing so it works for us.

We are upgrading the KVM next week, maybe this solves the issue.





[GLASSFISH-20814] Remote EJB call fails with newly created HashMap Created: 16/Sep/13  Updated: 08/Jan/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mduigou Assignee: russellgold
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux tomziWorkSchleppi 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


Tags: remote

 Description   

Original report follows. Key points are:

  • Failure occurs with Java SE 7u40. Does not occur with 7u25.
  • Significant changes occurred in HashMap implementation between 7u25 -> 7u40
  • The problem is not reproducible in simple unit test setup, only in context of Glassfish remote EJB.

Sample unit test (passes with both 7u25 and 7u40):

public class EmptyHashMapSerialization {
public static void main(String... args)

{ Map<String,String> empty1 = new HashMap<>(); Map<String,String> empty2 = serialClone(empty1); empty1.put("foo", "bar"); empty2.put("foo", "bar"); System.out.println("Success!"); }

public static <T> T serialClone(T object) {
try

{ ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(object); oos.close(); ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bis); return (T) ois.readObject(); }

catch(Throwable all)

{ throw new Error("Fatal error", all); }

}
}

Original Problem report:

Sending a newly created HashMap over a Remote EJB call in Glassfish and adding an entry to the HashMap in the EJB Method throws an ArrayIndexOutOfBoundsException. It seems that the Map thinks it was already initialized because the check if (table == EMPTY_TABLE) in the put method seems to be false (even if it should the true) -> Hash Seed value was not initialized (=0) when the exception occured.

This is reproducable on Glassfish but not in a normal Unit Test where we tried to serialize/deseriaize the Hashmap before adding a object via put(...)

REGRESSION. Last worked in version 7u25

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

  • create a new HashMap
  • do EJB call with HashMap
  • in the called Method add entry via put

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Entry is added to the HashMap
ACTUAL -
ArrayIndexOutOfBoundsException

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1761085646
at java.util.HashMap.put(HashMap.java:498) ~[na:1.7.0_40]

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Add and remove an entry before sending the HashMap in the EJB call.

SUPPORT :
YES



 Comments   
Comment by marina vatkina [ 16/Sep/13 ]

What is the full stack trace? Where is a remote EJB call in this test?

Comment by mduigou [ 16/Sep/13 ]

I have requested more info from the original reporter.

The sample unit test is what I used to verify that the problem is not reproducible in a non-ejb context.

Comment by marina vatkina [ 17/Sep/13 ]

Can I see the unit test that you use? The code above has nothing to do with an EJB.

Comment by perttierkkila [ 17/Sep/13 ]

This issue exists.

Preconditions:
1.7.0_40 or newer (1.7.0_60 tested also)
empty, intact HashMap
EJB-serialization

Result:
deserialized HashMap is faulty internally

Reason:
HashMap has been internally improved to use same final instance for empty transient table -variable:
static final Entry<?,?>[] EMPTY_TABLE = {};
transient Entry<K,V>[] table = EMPTY_TABLE;

New HashMap.put has a check for empty variable via instance check (if (table == EMPTY_TABLE)) and then does inflate for internal structure. But in EJB-deserialized HashMap table-variable contains a NEW instance of empty array. This causes inflate-check to fail and result is a mystic ArrayIndexOutOfBounds-exception.

HashMap.readObject contains a valid way to deserialize and above junit-test seems only to prove that HashMap serialization/deserialization works properly.

Comment by jyrkip [ 17/Sep/13 ]

Simple Maven project that demonstrates this bug using Arquillian and Glassfish Embedded edition can be found from https://github.com/sysart/glassfish-bug-20814

Comment by mduigou [ 17/Sep/13 ]

jyrkip: Thank you for adding a reproducing case. Having one definitely helps.

Comment by marina vatkina [ 17/Sep/13 ]

Do you see the same problem if it's a Local bean?

Comment by jyrkip [ 18/Sep/13 ]

No, then it works correctly.

Comment by marina vatkina [ 18/Sep/13 ]

In this case it's probably ORB serialization

Comment by jyrkip [ 20/Oct/13 ]

I updated the https://github.com/sysart/glassfish-bug-20814 to using jar -dependencies so I could get the sources easily, and investigated this a little bit. What I found out was that the reason seems to relate in the way the objects are copied.

First, the org.glassfish.pfl.dynamic.copyobject.impl.ClassCopierOrdinaryImpl::getSerializableConstructor(Class<?> cl) gets the first parent that doesn't implement Serializable[1]. When copying HashMap, this will be AbstractMap. Then the non-arg constructor of AbstractMap is called. This seems to cause that the initialisers in HashMap ( critically transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE; ) will not be called.

Second part of the problem seems to be in org.glassfish.pfl.dynamic.copyobject.impl.ClassCopierOrdinaryImpl::copy( Map<Object,Object> oldToNew, Object source, Object result ) throws ReflectiveCopyException. This method goes through every field of source [2] and copies them with Unsafe::putObject(Object o, long offset, Object x);. I think that this would replace the transient Entry<K,V>[] table in HashMap even if it was properly initialised.

This bug existed in OpenJDK 1.8.0-ea-b96 (or some version around that, can't remember), but in 1.8.0-ea-b111 everything works as the HashMap implementation has been reverted. With 7u45 this bug is still present.

[1]:
Class<?> initCl = cl;
while (Serializable.class.isAssignableFrom(initCl)) {
if ((initCl = initCl.getSuperclass()) == null)

{ return null; }

}

[2]:
for (int ctr=0; ctr<fieldOffsets.length; ctr++ )

{ fieldCopiers[ctr].copy( oldToNew, fieldOffsets[ctr], source, result ) ; }
Comment by russgold [ 24/Dec/13 ]

The problem is indeed the way the objects are copied. The logic in the code seems rather problematic; however, it works for other cases than empty HashMaps. A special case check works to fix the problem; it is not the way I'd prefer to fix it, but a more general fix will take longer and risks breaking other code. I will try to release the changes to PFL this week.

Comment by russgold [ 27/Dec/13 ]

I have released a new version of the Primitive Function Library (pfl) that fixes this issue. If you add:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.glassfish.pfl</groupId>
<artifactId>pfl-dynamic</artifactId>
<version>4.0.0-b004</version>
</dependency>
</dependencies>
</dependencyManagement>

To your POM, the problem should no longer exist (at least with the jars being obtained via the maven dependency mechanism). I will work on getting this into the next release of Glassfish.

Comment by Peter Butkovic [ 07/Jan/14 ]

progress on this one looks quite promising. thanks.

would it be possible to provide some reference to commits related (maybe with some public http links)? as I don't expect any 3.1.x releases to happen, still self-made backports might be an option for us.

Comment by russgold [ 07/Jan/14 ]

Here's the fix to pfl - https://java.net/projects/gmbal/sources/pfl/revision/51

which appears in org.glassfish.pfl:pfl:4.0.0-b004. The latest version of the orb, org.glassfish.corba:glassfish-corba:4.0.0-b008 has the changes and the source for glassfish itself has been updated.

Comment by Peter Butkovic [ 08/Jan/14 ]

thanks a lot for the fix reference!





[GLASSFISH-20776] when new InitialContext ,the java.lang.NullPointerException is happenning Created: 22/Aug/13  Updated: 23/Aug/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b71
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows



 Description   

when execute the following code

Properties props = new Properties();
props.setProperty("com.sun.appserv.iiop.loadbalancingpolicy","ic-based");
props.setProperty(ORBLocator.OMG_ORB_INIT_HOST_PROPERTY,
"10.167.234.33");
props.setProperty(ORBLocator.OMG_ORB_INIT_PORT_PROPERTY,
"23700");
InitialContext ic = new InitialContext(props);

the following Exception is happenning

Exception in thread "main" java.lang.NullPointerException
	at org.glassfish.enterprise.iiop.impl.NamingClusterInfoImpl.getEndpointList(NamingClusterInfoImpl.java:173)
	at org.glassfish.enterprise.iiop.impl.NamingClusterInfoImpl.initGroupInfoService(NamingClusterInfoImpl.java:99)
	at com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:168)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
	at javax.naming.InitialContext.init(InitialContext.java:242)
	at javax.naming.InitialContext.<init>(InitialContext.java:216)
	at Main.main(Main.java:22)


 Comments   
Comment by lzg5039 [ 22/Aug/13 ]

it is a style or it is a bug?

Comment by lzg5039 [ 22/Aug/13 ]

In method of initGroupInfoService get IP firstly,then initialize rrPolicy .But the metod of getEndpointList uses the rrPolicy which does not be initialized.

method:initGroupInfoService
final List<String> epList = getEndpointList(myEnv, defaultHost, defaultPort);
rrPolicy = new RoundRobinPolicy(epList);
method:getEndpointList
if (list.isEmpty()) {
    final String urlValue = (String)env.get(
            ORBLocator.JNDI_PROVIDER_URL_PROPERTY) ;
    list.addAll( rrPolicy.getEndpointForProviderURL( urlValue ) ) ;
}

if (list.isEmpty()) {
    String host = getEnvSysProperty( env,
            ORBLocator.OMG_ORB_INIT_HOST_PROPERTY) ;
    String port = getEnvSysProperty( env,
            ORBLocator.OMG_ORB_INIT_PORT_PROPERTY) ;

     if (host != null && port != null) {
        list.addAll(rrPolicy.getAddressPortList(host, port) ) ;
        logger.log(Level.WARNING, NO_ENDPOINT_SELECTED, new Object[]{host, port});
    }
}
Comment by lzg5039 [ 23/Aug/13 ]

please help me to review the following modified

method:getEndpointList
if (list.isEmpty()) {
    final String urlValue = (String)env.get(
            ORBLocator.JNDI_PROVIDER_URL_PROPERTY) ;
+    if(rrPolicy != null){
        list.addAll( rrPolicy.getEndpointForProviderURL( urlValue ) ) ;
+    } else {
+        if (urlValue != null) {
+           try {
+                IiopUrl providerURL = new IiopUrl(urlValue);
+                IiopUrl.Address iiopUrlAddress = 
+                    (IiopUrl.Address)(providerURL.getAddresses().elementAt(0));
+                String host = iiopUrlAddress.host;
+                int portNumber = iiopUrlAddress.port;
+                String port = Integer.toString(portNumber);
+                list.add(host + ":" + port);
+            } catch (MalformedURLException me) {
+                logger.log(Level.WARNING, RoundRobinPolicy.PROVIDER_EXCEPTION, new Object[]{me, urlValue});
+            }
+        }
+    }
}

if (list.isEmpty()) {
    String host = getEnvSysProperty( env,
            ORBLocator.OMG_ORB_INIT_HOST_PROPERTY) ;
    String port = getEnvSysProperty( env,
            ORBLocator.OMG_ORB_INIT_PORT_PROPERTY) ;

     if (host != null && port != null) {
+        if(rrPolicy != null){
            list.addAll(rrPolicy.getAddressPortList(host, port) ) ;
            logger.log(Level.WARNING, NO_ENDPOINT_SELECTED, new Object[]{host, port});
+        } else {
+            list.add(host + ":" + port);
+        }    
+     }
}





[GLASSFISH-20738] No jndi entries, remote ejb not working Created: 02/Aug/13  Updated: 06/Aug/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: marcing Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 6.4, Java 1.6.0_45 64bit



 Description   

I have application with remote session beans I'd like to access remotely from another Glassfish instance (on another host).

I can see JNDI names of these beans after deploy (in server.log).

Executing list-jndi-entries command gives:

ejb.MySessionRemote: javax.naming.Reference
ejb: com.sun.enterprise.naming.impl.TransientContext
jdbc: com.sun.enterprise.naming.impl.TransientContext
java:global: com.sun.enterprise.naming.impl.TransientContext
ejb.MessageEntityFacadeRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
ejb.MySessionRemote#ejb.MySessionRemote: javax.naming.Reference
ejb.MessageEntityFacadeRemote: javax.naming.Reference
ejb.MySessionRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
UserTransaction: com.sun.enterprise.transaction.TransactionNamingProxy$UserTransactionProxy
jms: com.sun.enterprise.naming.impl.TransientContext
ejb.beans.TestBeanRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
ejb.MessageEntityFacadeRemote#ejb.MessageEntityFacadeRemote: javax.naming.Reference
com.sun.enterprise.container.common.spi.util.InjectionManager: com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
ejb.beans.TestBeanRemote: javax.naming.Reference
ejb.beans.TestBeanRemote#ejb.beans.TestBeanRemote: javax.naming.Reference

So far looks good, but when I try to access one of these beans using:
corbaname:iiop:<hostname>:3700#<jndi-name>
I get not found exceptions. For debugging process I've created servlet that will access that remote Glassfish and list bounds inside its context using code like that:

InitialContext ic = new InitialContext();
NamingEnumeration<NameClassPair> ne = ic.list("corbaname:iiop:<hostname>:3700");

after that I print out ne elements, and here's what I get:

SerialContextProvidercom.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub
INITIAL_GIScom.sun.corba.ee.impl.folb.InitialGroupInfoService$_InitialGIS_DynamicStub

I've deployed the same app on Glassfish 3.1.2(build 23) on another host.

list-jndi-entries output:

ejb.MySessionRemote: javax.naming.Reference
ejb: com.sun.enterprise.naming.impl.TransientContext
jdbc: com.sun.enterprise.naming.impl.TransientContext
java:global: com.sun.enterprise.naming.impl.TransientContext
ejb.MessageEntityFacadeRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
ejb.MySessionRemote#ejb.MySessionRemote: javax.naming.Reference
ejb.MessageEntityFacadeRemote: javax.naming.Reference
ejb.MySessionRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
UserTransaction: com.sun.enterprise.transaction.TransactionNamingProxy$UserTransactionProxy
jms: com.sun.enterprise.naming.impl.TransientContext
ejb.beans.TestBeanRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
ejb.MessageEntityFacadeRemote#ejb.MessageEntityFacadeRemote: javax.naming.Reference
com.sun.enterprise.container.common.spi.util.InjectionManager: com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
ejb.beans.TestBeanRemote: javax.naming.Reference
ejb.beans.TestBeanRemote#ejb.beans.TestBeanRemote: javax.naming.Reference

Using my servlet gave me this:

SerialContextProvidercom.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub
java:globalcom.sun.jndi.cosnaming.CNCtx
INITIAL_GIScom.sun.corba.ee.impl.folb.InitialGroupInfoService$_InitialGIS_DynamicStub
ejb.beans\.TestBeanRemote__3_x_Internal_RemoteBusinessHome__com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub
ejb.MySessionRemote__3_x_Internal_RemoteBusinessHome__com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub
ejb.MessageEntityFacadeRemote__3_x_Internal_RemoteBusinessHome__com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub

On that Glassfish (3.1.2) I can remotely access every bean, using portable on non-portable name.

Ahhh, I almost forget. My app from which I access these beans is deployed on my local PC (Glassfish 3.1.2.2). There are no firewalls blocking connections to any of these two dev hosts. Glassfish 3.1.2.2 is current I think. Downloaded today from official site. Update tool shows no updates available.

Thanks,
Marcin



 Comments   
Comment by marcing [ 06/Aug/13 ]

Got it running. The source of problem was /etc/hosts. I had hostname (by hostname I meant name of machine without domain) assigned to 127.0.0.1, after changing it to external IP everything is ok. Now I have remote access to my beans.

Case closed!

Thanks,
Marcin

Comment by marcing [ 06/Aug/13 ]

On the other hand...In admin console I can change address on which orb listener is running. But with wrong /etc/hosts I won't have remote access to beans...even if listener is set to listen on external ip...





[GLASSFISH-20464] Timeout when stop the domain with --force=false after deployed the ejb application Created: 03/May/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Jeremy_Lv Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All



 Description   

I have found a strange situation that it will be timeout if I stop the DAS or instance with -force=false after I have deployed an ejb application. Here's my reproduced steps:

1). asadmin start-domain

2). asadmin deploy Hello.jar
Application deployed with name Hello.
Command deploy executed successfully.

3). asadmin stop-domain -force=false
Waiting for the domain to stop .......................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-domain failed.

4).jstack jvm_pid > jstack.txt(I have attached the jstack file).

5). asadmin start-domain
Waiting for domain1 to start .Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_E
RROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../.
./../src/share/back/debugInit.c:750]

Command start-domain failed.

Then the domain can't be start normally, I think somewhere must lock the file because of deploy the ejb application. But I don't the exactly reason about this.

BTW: <1>. The exception will not come out if we stop the domain or cluster with default option of -force.
<2>. The exception will not come out if stop the DAS and cluster after only deployed the web application.



 Comments   
Comment by Jeremy_Lv [ 03/May/13 ]

Hi, Tom

Hers's the detailed informations about my ejb application

HelloWorld.java
package clchun.ejb3.Impl;

import javax.ejb.Stateless;
import clchun.ejb3.HelloWorld;

@Stateless
public class HelloWorldBean implements HelloWorld {
    public String Say(String name){
        return name + "Say: Hello World";
    }
}
HelloWorld.java
package clchun.ejb3;

import javax.ejb.Remote;

@Remote
public abstract interface HelloWorld
{
  public abstract String Say(String paramString);
}

There's no other file except the above two class file

Comment by Tom Mueller [ 03/May/13 ]

The non-daemon thread that shows up in the jstack output in this case is:

"Thread-30" prio=6 tid=0x34584800 nid=0xb28 in Object.wait() [0x33ddf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive.run(Util.java:818)

  • locked <0x12130ba8> (a com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive)
Comment by Tom Mueller [ 03/May/13 ]

Assigning to the orb component based on the CORBA reference in the non-daemon thread stack trace.
Please evaluate whether this is a stopper for 4.0.

Comment by Harshad Vilekar [ 04/May/13 ]

This is not a stopper for 4.0.

When the remote app is deployed, ORB is initialized, which starts the KeepAlive thread in non daemon mode. That's the current design. The default stop-domain command takes care of terminating this thread.

With "--force=false" option, the thread is never terminated during shutdown process, and is keeping the VM from existing. There are two options to work around this:

1. use the default stop-domain command without "--force=false" flag.

2. undeploy all remote apps, restart the domain to shutdown the ORB, and then try "stop-domain --force=false"

Possible resolution is to register a shutdown hook, and write a call back method to terminate KeepAlive thread, and clean up any other ORB resources. This needs further evaluation.

Comment by Tom Mueller [ 06/May/13 ]

Another possible resolution may be to call Thread.setDaemon(true) on the thread after it is created. Then there is no need for a shutdown hook.





[GLASSFISH-20443] ORBPackage.InvalidName: TransactionCurrent not found Created: 30/Apr/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Seen the following error reported during tx clustered devtest on hudson:

[2013-04-25T07:26:40.591-0700] [glassfish 4.0] [SEVERE] [jts.unexpected_error_in_create_transaction_manager] [javax.enterprise.system.core.transaction.com.sun.jts.jta] [tid: _ThreadID=105 _ThreadName=Recovery Helper Thread] [timeMillis: 1366900000591] [levelValue: 1000] [[
JTS5043: Unexpected error occurred while creating transaction manager instance
org.omg.CORBA.ORBPackage.InvalidName: TransactionCurrent not found
at com.sun.corba.ee.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1262)
at com.sun.jts.jta.TransactionManagerImpl.<init>(TransactionManagerImpl.java:189)
at com.sun.jts.jta.TransactionManagerImpl.getTransactionManagerImpl(TransactionManagerImpl.java:177)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.setTransactionManager(JavaEETransactionManagerJTSDelegate.java:457)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.recover(JavaEETransactionManagerJTSDelegate.java:418)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.recover(JavaEETransactionManagerSimplified.java:297)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverXAResources(ResourceRecoveryManagerImpl.java:256)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverXAResources(ResourceRecoveryManagerImpl.java:337)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.postConstruct(ResourceRecoveryManagerImpl.java:108)



 Comments   
Comment by marina vatkina [ 30/Apr/13 ]

This bug is for the ORB behavior





[GLASSFISH-20374] ORB threadpool contention and wait Created: 22/Apr/13  Updated: 22/Apr/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: amitsehgal Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.1.2.2 (build 5)



 Description   

We are calling EJB remotely from a standalone java clients. We are facing thread contention issue under heavy load. The ORB Threadgroup worker threads are waiting on WorkQueue. The waiting time varies between 10 - 100 milliseconds. Although the application keeps running for this load but response times are very high.

here are the thread profling results. We see lot of these.

Blocked on monitor id 269 (a com.sun.corba.ee.impl.orbutil.threadpool.WorkQueueImpl) since 24:53.484.942
Waiting thread: p: default-threadpool; w: 80 [ORB ThreadGroup 0]
Blocked on monitor id 269 (a com.sun.corba.ee.impl.orbutil.threadpool.WorkQueueImpl) since 24:53.486.385
Waiting thread: p: default-threadpool; w: 78 [ORB ThreadGroup 0]
Blocked on monitor id 269 (a com.sun.corba.ee.impl.orbutil.threadpool.WorkQueueImpl) since 24:53.488.038
Waiting thread: p: default-threadpool; w: 82 [ORB ThreadGroup 0]
Blocked on monitor id 269 (a com.sun.corba.ee.impl.orbutil.threadpool.WorkQueueImpl) since 24:53.488.163
Waiting thread: p: default-threadpool; w: 83 [ORB ThreadGroup 0]






[GLASSFISH-19803] usage of internal proprietary API in appserver/orb/org-iiop Created: 08/Mar/13  Updated: 08/Mar/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b79
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, orb, proprietary-api, warning

 Description   
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[45,29] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[295,22] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[295,48] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[403,44] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[405,8] IiopUrl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/RoundRobinPolicy.java:[406,17] IiopUrl is internal proprietary API and may be removed in a future release





[GLASSFISH-19848] NPE occurs when EJB Container initialized on DAS(server) Created: 13/Mar/13  Updated: 13/Mar/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Wu Jie Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb_container, gms, orb

 Description   

NullPointerException occurs when EJB Container initialized on DAS(server) which the domain has cluster definition.
■ Reproduce manner
1.create-cluster ijserver
2.create-local-instance instance1
3.stop-domain
4.start-domain
5.deploy --target server ejbApp(★NPE occurs)

or

1.create-cluster ijserver
2.create-local-instance instance1
3.deploy --target server MyApplication.jar
4.stop-domain
5.start-domain(★NPE occurs)

■ the stack trace of NullPointerException

#|2013-03-07T17:34:24.908+0900|SEVERE|||_ThreadID=1;_ThreadName=main;|java.lang.NullPointerException
at
org.glassfish.enterprise.iiop.impl.IiopFolbGmsClient.getAllClusterInstanceInfo(IiopFolbGmsClient.java:443)
at
org.glassfish.enterprise.iiop.impl.IiopFolbGmsClient.<init>(IiopFolbGmsClient.java:152)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.setFOLBProperties(GlassFishORBManager.java:422)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:458)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:152)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:219)
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:824)
at
com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:569)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
at
org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
at
org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:305)
at
org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:108)
at
org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at
com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at
com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at
com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at
com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at
com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at
com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at
com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at
com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]


 Comments   
Comment by Wu Jie [ 13/Mar/13 ]

when initial ejb container it need acquire the cluster info according to the current server instance as the following source

org.glassfish.enterprise.iiop.impl.IiopFolbGmsClient
    private Map<String,ClusterInstanceInfo> getAllClusterInstanceInfo() {
        final Cluster myCluster = myServer.getCluster() ;
        fineLog( "getAllClusterInstanceInfo: myCluster {0}", myCluster ) ;

        final Config myConfig = getConfigForServer( myServer ) ;
        fineLog( "getAllClusterInstanceInfo: myConfig {0}", myConfig ) ;

        final Map<String,ClusterInstanceInfo> result =
            new HashMap<String,ClusterInstanceInfo>() ;

        for (Server server : myCluster.getInstances()) {//★myCluster is null when myServer is DAS(server)
            ClusterInstanceInfo cii = getClusterInstanceInfo( server, myConfig,
                false) ;
            if (cii != null) {
                result.put( server.getName(), cii ) ;
            }
        }

        fineLog( "getAllClusterInstanceInfo: result {0}", result ) ;
        return result ;
    }

but the source above neglects the pattern of DAS(server), from which can not get any cluster info,
in this pattern the NPE occurs.

Comment by marina vatkina [ 13/Mar/13 ]

-> ORB





[GLASSFISH-19313] warning: Supported source version 'RELEASE_6' from annotation processor 'org.glassfish.corba.annotation.processing.ExceptionWrapperProcessor' less than -source '1.7' Created: 09/Nov/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b62_ms6
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This warning is reported on compilation of ejb devtests after switch to JDK7



 Comments   
Comment by Harshad Vilekar [ 14/Feb/13 ]

The warnings will go away once the ORB build is moved to JDK1.7.





[GLASSFISH-18692] NPE in ServerGroupManager.java:591 Created: 05/May/12  Updated: 13/Feb/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mhankus Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'was looking for one of problems with glassfish, and when I enabled logging on all components (it is test server, so it was not a problem), some NPE can be observed in ServerGroupManager (two stacktraces below)

[#|2012-05-05T16:24:19.091+0200|FINE|glassfish3.1.2|javax.enterprise.resource.corba.ORBUtil|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.corba.ee.spi.orbutil.logex.Wrapper
Generator;MethodName=handleFullLogging;|IOP00010020: Error in ServerGroupManager
org.omg.CORBA.UNKNOWN: FINE: IOP00010020: Error in ServerGroupManager vmcid: OMG minor code: 20 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy191.serverGroupManagerException(Unknown Source)
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_star(ServerGroupManager.java:608)
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_reply(ServerGroupManager.java:503)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorEndingPoint(InterceptorInvoker.java:702)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIEndingPoint(PIHandlerImpl.java:673)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.runInterceptors(CorbaMessageMediatorImpl.java:2189)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2101)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2072)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponse(CorbaMessageMediatorImpl.java:1921)
at com.sun.corba.ee.impl.protocol.IsA.invoke(SpecialMethod.java:143)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:494)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:126)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:273)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:395)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
at com.sun.corba.ee.impl.folb.InitialGroupInfoService.bindName(InitialGroupInfoService.java:209)
at com.sun.corba.ee.impl.folb.InitialGroupInfoService.<init>(InitialGroupInfoService.java:177)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:611)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:152)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:219)
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:824)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:508)
at com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:142)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:121)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:299)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:105)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)

at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_star(ServerGroupManager.java:591)
... 54 more

#]

[#|2012-05-05T16:24:19.091+0200|FINE|glassfish3.1.2|javax.enterprise.resource.corba.ORBUtil|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.corba.ee.spi.orbutil.logex.Wrapper
Generator;MethodName=handleFullLogging;|IOP00010020: Error in ServerGroupManager
org.omg.CORBA.UNKNOWN: FINE: IOP00010020: Error in ServerGroupManager vmcid: OMG minor code: 20 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy191.serverGroupManagerException(Unknown Source)
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_star(ServerGroupManager.java:608)
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_reply(ServerGroupManager.java:503)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorEndingPoint(InterceptorInvoker.java:702)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIEndingPoint(PIHandlerImpl.java:673)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.runInterceptors(CorbaMessageMediatorImpl.java:2189)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2101)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2072)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponse(CorbaMessageMediatorImpl.java:1921)
at com.sun.corba.ee.impl.protocol.IsA.invoke(SpecialMethod.java:143)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:494)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:126)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:273)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:395)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
at com.sun.corba.ee.impl.folb.InitialGroupInfoService.bindName(InitialGroupInfoService.java:209)
at com.sun.corba.ee.impl.folb.InitialGroupInfoService.<init>(InitialGroupInfoService.java:177)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:611)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:152)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:219)
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:824)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:508)
at com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:142)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:121)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:299)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:105)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.corba.ee.impl.folb.ServerGroupManager.send_star(ServerGroupManager.java:591)
... 54 more

#]


 Comments   
Comment by shreedhar_ganapathy [ 13/Feb/13 ]

-> Harshad for eval and release targetting





[GLASSFISH-18771] [PERF] Remote EJB lookups are slow due to repeated class loading Created: 31/May/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG

 Description   

Performance tests of remote lookups of EJBs are lagging.

One key contributor to this is the excessive time spent in looking up classes in the class loader; the JDKBridge class pends a lot of time loading classes (which is in turn quite expensive because the lower classes throw a lot of ClassNotFoundExceptions along the way). We need to cache the classes better to avoid these lookups.

In fact, I see that in the JDKBridge class there already is a class cache, but it has been disabled because it doesn't work correctly between applications. We must fix that; when I enabled it for our throughput test of EJB lookups, performance improved by 25%.



 Comments   
Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-18723] [PERF]Excessive thread contention in orb code Created: 13/May/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b36
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: amitagarwal Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-18724 [PERF] Trade2 benchmark has regressed... Open
Tags: PSRBUG

 Description   

IIOP/orb performance has regressed a lot in 4.0. This has affected client-side as well as server side performance. Thread dump indicates that a lot of contention due to SynchronizedHolder.content. Please note that similar issue (# 15392) was filed during 3.1 time too. Below is a thread pointing the contention,

"Thread-7" prio=10 tid=0x00002aaab05d5000 nid=0x9bd5 waiting for monitor entry [0x0000000042ac9000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.glassfish.pfl.basic.contain.SynchronizedHolder.content(SynchronizedHolder.java:63)

  • waiting to lock <0x00000000e08c3120> (a org.glassfish.pfl.basic.contain.SynchronizedHolder)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.handleIndirection(CDRInputStream_1_0.java)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1041)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:930)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:923)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:913)
    at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
    at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:389)
    at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:542)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
    at java.util.HashMap.readObject(HashMap.java:1030)
    at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1830)
    at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1212)
    at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:423)
    at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:307)
    at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:273)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1010)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1118)
    at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
    at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2160)
    at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2402)
    at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1222)
    at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:423)
    at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:307)
    at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:273)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1010)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1118)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:930)
    at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
    at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
    at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:604)
    at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:770)
    at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:451)
    at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:298)
    at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:482)
    at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:201)
    at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
    at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
    at weblogic.performance.benchmarks.rmi._EJBRMIBenchmarks_DynamicStub.getSerializable(weblogic/performance/benchmarks/rmi/_EJBRMIBenchmarks_DynamicStub.java)
    at weblogic.performance.benchmarks.rmi.clients.GetSerializableUser.op(RMIUser.java:320)
    at weblogic.performance.benchmarks.rmi.clients.RMIUser.execute(RMIUser.java:70)
    at weblogic.performance.utils.controller.ClientThread.run(ClientThread.java:81)


 Comments   
Comment by russgold [ 09/Jul/12 ]

The code referred to here appears to be fairly old. I see no references to SynchronizedHolder in the current orb code. GF 4 (as of Jun 29) now uses the 4.0 ORB. If you can get that code, could you please rerun this test to see if the contention still exists, and if so, where?





[GLASSFISH-19186] ORB Test Coverage improvements Created: 18/Oct/12  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-11941 Improve CORBA testing Resolved

 Description   

Tracking issue for ORB test coverage / code coverage improvements:

  • Add unit tests and bug verification tests to dev test suite.
  • Automate performance testing with ability to identify performance regressions.
  • Automate ORB CTS tests on dev builds.
  • Dev integration of Corba SQE tests.
  • Improve dev test execution framework result reporting. Complete port to Junit/testNG.
  • StandardTest, Maribor
    Related issue: GLASSFISH-11941





[GLASSFISH-19095] POARemoteReferenceFactory keeps a strong reference to an ear's class loader Created: 21/Sep/12  Updated: 13/Dec/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: bebbo Assignee: russgold
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any



 Description   

package org.glassfish.enterprise.iiop.impl;

Memory leak after undeployment of an ear.

  • deploy an ear with web services and jpa
  • invoke at least one ws which uses jpa
  • deploy the same ear again

=> the first deployed ear is not properly undeployed. (VisualVM is showing two instances of EarClassLoader

It's caused by a hard reference to the ear's class loader.



 Comments   
Comment by bebbo [ 21/Sep/12 ]

ClassLoader appClassLoader

Comment by shreedhar_ganapathy [ 13/Dec/12 ]

->orb
->Russ for further eval





[GLASSFISH-18988] Classloading broken during reading object from Corba request for generated classes in com.sun.jts.codegen.* packages Created: 09/Aug/12  Updated: 24/Aug/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gray Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)



 Description   

I'm trying to make remote EJB calls over ssl with mutual authentication work (this is probably have nothing to do with bug itself but worth mentioning)

There is following part inside read_Object(Class clz) method of CDRInputStream_1_0 class:

...
        if (clz == null) {
            RepositoryId rid = RepositoryId.cache.getId( ior.getTypeId() ) ;
            String className = rid.getClassName() ;
...
                try {
                    stubFactory = sff.createStubFactory(className,
                        isIDLInterface, codeBase, (Class<?>) null,
                        (ClassLoader) null);
                } catch (Exception exc) {
                    stubFactory = null;
                }
...

When it tries to get classname from RepositoryId for any classes in com.sun.jts.codegen.otsidl or com.sun.jts.codegen.jtsxa packages it will get it wrong - i.e. instead "com.sun.jts.codegen.otsidl.JCoordinator" it will get only "otsidl.JCoordinator". Of course that class name cannot be resolved during createStubFactory call and ends up with ClassNotFoundException.
This happens because generated classes like JCoordinatorHelper and JCoordinatorPOA (and others) use for serialization of JCoordinator instances id strings like
"IDL:otsidl/JCoordinator:1.0" and RepositoryId parse that strings to class names accordingly.
Since this classes are generated I assume that problem either in jts.idl file (where it is actually? no sign of it in repository) or in generation configuration.

P.S. By the way JCoordinator instance only goes through wire if you invoke remote EJB inside some transaction, without transactional context invocation works like a charm. Most of examples I have seen in the internet were about invoking remote EJB from appclient. I'm invoking it from other glassfish instance on same machine.



 Comments   
Comment by gray [ 15/Aug/12 ]

Any reaction?

Comment by marina vatkina [ 15/Aug/12