[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-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-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-17151] EJB remote deployed on GF 3.1 behind a NAT unaccessible via a simple Java app Created: 05/Aug/11  Updated: 16/Nov/16

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.1.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.

Comment by lordvlad [ 16/Nov/16 ]

Is there any progress on this issue? Is it supposed to be fixed in 4.1.1? Because we have the same issue now with 4.1.1 and it is kind of a showstopper.





[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-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-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-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-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-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-18632] orb-connector brings in a lot of dependencies Created: 16/Apr/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
Fix Version/s: 4.1.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: 20/Dec/16

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

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
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-17281] javax.ejb.AsyncResult in Remote interfaces with DTOs generates ClassCastException on client Created: 08/Sep/11  Updated: 20/Dec/16

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

Type: Bug Priority: Critical
Reporter: vins4java Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
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!

Comment by wfsaxton [ 23/May/16 ]

This bug is very old. Is it really still being worked on? Is there a workaround available?

This issue still exists in GF 4.1.





[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-12086] Remote IIOP lookup with CSiv2 (SSL) not working Created: 01/Jun/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1
Fix Version/s: 4.1.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-15224] Accessing context from remote application client fails Created: 15/Dec/10  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.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-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-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-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-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-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-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-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-15490] IIOP failover Dev Test is failing Created: 07/Jan/11  Updated: 19/Dec/16

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.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-15637] IIOP Loadbalancing not happening Created: 20/Jan/11  Updated: 19/Dec/16  Due: 01/Feb/11

Status: Reopened
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_dev
Fix Version/s: future release

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

Attachments: File patch.tgz    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP Loadbalancing not happening with certain apps

The Initial context is created as follows

public void createContextForACC()
{
try

{ InitialContext initial = new InitialContext(); myEnv = (InitialContext)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

All new ic creations are going to same instance



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

I don't understand what is failing here. Is this an issue about some of the failover
tests? Which ones?

Or is it an issue about how the InitialContext is created?

I also have no idea what a lookup of java:comp/env/ejb is supposed to do.
This is not part of IIOP or FOLB.

Please clarify or close this issue.

Comment by gopaljorapur [ 21/Jan/11 ]

The loadbalancing is not happening, all new ic creations happen on one random instance in the cluster

Comment by Ken Cavanaugh [ 25/Jan/11 ]

This issue does not currently correctly describe the observed problem.
I THINK (from email and conversation with Gopal) that the problem is
that loadbalancing does not happen when the endpoints property is specified
in the app client command, but DOES happen when the endpoints property
is passed to the (first) new InitialContext call.

I will investigate that question in my testing shortly.

Comment by Ken Cavanaugh [ 26/Jan/11 ]

My test (same as the 14867 existing instance case) works with -Dcom.sun.appserver.iiop.endpoints specified,
but fails with appclient -targetserver. I've sent email to Tim to see if this is a configuration error in
my code, or an error in the ACC argument parsing.

Comment by Ken Cavanaugh [ 30/Jan/11 ]

This patch contains two fixes:

1. The sticky context reference count has been fixed to avoid extra increments, which
creates a "stuck" condition in which the same SerialContext underlying the InitialContext
call is used all the time. This fix is in glassfish-naming.

2. I added code to the ORB to detect and specially label name service implementations.
The FOLB server group manager then arranges to always send a membership label
update on the reply to any name server invocation. This means that the
lookup call on the new InitialContext will get any updates to the cluster shape.
This in turn prevents the situation where the client is always obtaining up-to-date
references from naming, but the new InitialContext call is not informed of the changes
(which happens only the the ClientGroupManager receives a response contains an
updated IOR for a membership label change).

Just unpatch the patch into the modules directory as usual.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in the following test scenario (which should have
been added earlier to this issue):

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test

This fails because LB happens to only one instance.

How much effort is required to fix it?
I have the fixes made, and the IIOP FOLB dev test passes.
Fixes are in the ORB (new support for labelling object implementations as being in a name service)
and in glassfish-naming (Fixes in how endpoint lists are merged in RoundRobinPolicy,
and fixes in sticky context reference counting in SerialContext)

What is the risk of fixing it? (Risk)
Low. We have good test coverage for all areas. The only likely impact is on IIOP FOLB.
Other functions of the ORB are unaffected by these changes.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
I don't think a reasonable workaround exists.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
Yes: IIOP FOLB dev test test15736.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The various tests that were failing that caused this issue to be filed (Gopal has the tests).

When will a tested fix be ready for integration?
Probably 1/31/11-2/1/11.

Comment by gopaljorapur [ 31/Jan/11 ]

he issue in 15637 is about IIOP Loadbalancing not happening , Scenario is as follows (I will update the issue with this scenario)

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client

Comment by Chris Kasso [ 31/Jan/11 ]

Approved for RC2.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

At this point, for tracking purposes, 15637 is for the scenario I outlined above:

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test (which should show LB across running instances)

It's TOO LATE to change the test scenario for 15637, especially since you did not include a sufficient
description initially. I have clearly identified some defects here that need to be fixed,
so please file a NEW issue for the scenarios you have identified above. Please also indicate in any
new issues whether or not stateful vs. stateless EJBs make any difference. This does not matter
to the ORB at all, but some of your tests seem to indicate failures on the SFSB side only.
If this matters, I'll also need to add SFSB support to the dev tests.

Comment by gopaljorapur [ 31/Jan/11 ]

I have opened an issue 15768 for the Loadbalancing issue mentioned in my earlier comment

Comment by Ken Cavanaugh [ 31/Jan/11 ]

Fixed in GF rev 44807.
This includes integration of ORB version 3.1.0-b025.

Comment by gopaljorapur [ 17/Feb/11 ]

With old styled apps, this issue is not fixed

Comment by Ken Cavanaugh [ 17/Feb/11 ]

I was certain I fixed this, but I'll test it again, and target it for
3.2.





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

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.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-15571] Create Resource Adapter Config is throwing an exception if jms is already started Created: 14/Jan/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1.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-18488] Getting EJB Container initialization error Created: 08/Mar/12  Updated: 20/Dec/16

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

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

suse linux,

java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.3) (suse-7.3-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)


Attachments: Text File server.log    

 Description   

[#|2012-03-08T19:24:55.820+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=10;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load m
ethod
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:242)
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:616)
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.ejb.containers.BaseContainer.<init>(BaseContainer.java:628)
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)
... 26 more

#]


 Comments   
Comment by marina vatkina [ 08/Mar/12 ]

There should be some other exception in the log prior to this one. Looks like ORB didn't start.

Comment by byteschubser [ 08/Mar/12 ]

I looked into the log, and there is only one other entry before that one. It happened right after starting the glassfish with an deployed ear. The other messages are info level.

[#|2012-03-08T19:24:48.828+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=10;_ThreadName=Thread-2;|WEB0355: network-listener [http-listener-2] referenced by virtual server [server] does not exist|#]

Comment by marina vatkina [ 08/Mar/12 ]

May be even earlier? How did you install GlassFish? Are you running a default install? Is it a cluster or a stand-alone instance?

Comment by byteschubser [ 12/Mar/12 ]

Even after the starts before, there did'nt occur another exception. It is a default install. Stand-alone instance. Installation by zip.

Comment by marina vatkina [ 12/Mar/12 ]

Can you attach the complete server.log?

Comment by marina vatkina [ 13/Mar/12 ]

It looks like some synchronization error because your server was restarted several times prior to that without any problem. Can you attach a reproducible test case?

For now I'm transferring this to ORB as it somehow returns null for the protocolManager...

Comment by byteschubser [ 14/Mar/12 ]

I'm sorry, but this isn't really reproduceable. But sometimes we get some CORBA NOPERMISSION when trying to connect to the server via rmi. I'm not sure if this is connected to this issue. There is an execption that lazy loading the iiop listener is not allowed.

Comment by Harshad Vilekar [ 14/Mar/12 ]

Are you using default settings in domain.xml for <iiop-service> element ? Or is anything modified ?

Does netstat show iiop ports in "LISTEN" state ?
$ netstat -an | grep 3700
.3700 *. 0 0 49152 0 LISTEN
$ netstat -an | grep 3820
.3820 *. 0 0 49152 0 LISTEN
$ netstat -an | grep 3920
.3920 *. 0 0 49152 0 LISTEN





[GLASSFISH-18402] EJB lookup problem with webstart; multithreaded use of same client-side proxy? Created: 23/Feb/12  Updated: 20/Dec/16

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

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

Attachments: Text File FastReuseOfInitialContextInJWS.txt    

 Description   

Our enterprise application contains an EJB module and the application client. The remote jndi lookup in the application client works fine, if the client stub runs with the appclient shell script. But when the application is executed via webstart, the beans won't be located properly due to the following error:

Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacede.beans.einkauf.MyServiceBeanRemote [Root exception is java.lang.IllegalArgumentException: java.lang.ClassCastException@532c81b7]
	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:304)
	at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
	... 15 more
Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException@532c81b7
	at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
	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:422)
	... 19 more

Maybe a cache issue, but we have no clue what goes wrong here.



 Comments   
Comment by Tim Quinn [ 23/Feb/12 ]

Can you attach your application to this issue so we can try to reproduce the problem from here?

Also, did you try clearing the Java Web Start cache on your client system and relaunching?

(Yes, this requires Java Web Start to download all the GlassFish system JARs again which can take a while as I'm sure you've experienced.)

Comment by andydr [ 23/Feb/12 ]

The application is very complex with about 60 EJBs and requires a JDBC datastore. I can try to build a corresponding example.

And yes, I cleared the Web Start cache.

Comment by Tim Quinn [ 23/Feb/12 ]

I am getting some help from the EJB team to direct where we need to look.

Also, what Java version are you running on the client?

Comment by andydr [ 23/Feb/12 ]

The client runs with 1.6.0_29.

Just some details on the ejb lookup. The @Remote annotated interface is
retrieved with InitialContext#lookup(<interfaceName>.class.getName()) and not injected with @EJB.

I found out, that the problematic remote interfaces are looked up multiple times during startup (in the main-method).
When I introduce lazy initialization for these stateless session beans and reuse it, the problem is gone.

During runtime multiple lookups for other stateless session beans are no problem.

Comment by marina vatkina [ 23/Feb/12 ]

How does your impl class look like? Does it have a business method called 'create'?

Comment by andydr [ 23/Feb/12 ]

The SLSB looks like this

 
@Stateless
public class MyServiceBean implements MyServiceBeanRemote {
    @Override
    public MyService create() {
        MyService art = new MyService();
        em.persist(art);
        return art;
    }
}

So, yes it has a business method 'create'. Is something wrong with this?

Comment by marina vatkina [ 23/Feb/12 ]

Does it make any difference if you rename 'create' to something else?

Comment by andydr [ 23/Feb/12 ]

Marina, the problem is NOT gone, when I rename the 'create' method.

One very last question: Quite often I get the following error:

org.omg.CORBA.COMM_FAILURE: WARNUNG: IOP00410037: Timeout while reading data in buffer manager vmcid: OMG minor code: 37 completed: No

The configuration TCP Read Timeout is set to 30secs! Is there another ORB configuration parameter available to solve
this issue?

Comment by andydr [ 23/Feb/12 ]

Just a reminder, the problem (ClassCastException during ejb lookup) happens only under Webstart. When the application stub is launched via the appclient script, it does not occur!

Apologize Marina, after a couple of webstart startups I feel, the timeout problem relates to the ClassCastException. Since sometimes the application starts up without any problems, but sometimes with read timeout exception and ClassCastExc.

A cross-check with appclient script showed the read timeout exception but no ClassCastExc.

Comment by marina vatkina [ 24/Feb/12 ]

com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422) calls a generated "create(String)" method. So my initial guess was that you also have such method in your remote interface, and the match happens correctly in ACC and not in JWS. But if renaming didn't help, it's not the cause of the problem.

Comment by Tim Quinn [ 24/Feb/12 ]

andydr,

Is it the Java Web Start launch that sometimes works and sometimes does not?

Or does Java Web Start always fail and appclient launches sometimes work and sometimes not?

I long time ago I think I have seen cases where ORB failures of certain types can be reported as other types of errors.
I am not sure that is happening in this case but given the ORB errors you see sometimes perhaps this is a similar case.

Comment by andydr [ 24/Feb/12 ]

Tim, the application launch works in either case. But the ClassCastException during ejb lookup occurs in JWS.

BTW: The ClassCastExc happens even without the read timeout and is also unrelated to specific beans. I.e. with each application startup the ClassCastExc happens for a different bean.

java.lang.ClassCastException@4c1e6823]
	at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)

What about JIRA#15775, can this class loader issue be linked to my problem?

Thanks, Andreas

Comment by marina vatkina [ 24/Feb/12 ]

Does lookup of the EJBs work in JWS?

Comment by Harshad Vilekar [ 24/Feb/12 ]

andydr,

Try increasing com.sun.corba.ee.transport.ORBTCPTimeouts.

Also, try increasing com.sun.corba.ee.transport.ORBTCPConnectTimeouts. Defaults are: 250:60000:100:5000 (max is 60 seconds).
"It controls how the ORB behaves on the client side when attempting to connect to an IOR (the wire rep of an EJB reference)."

Please see this blog for details about these properties:
https://blogs.oracle.com/ejcorba/entry/more_on_tcp_timeouts_in
https://blogs.oracle.com/ejcorba/entry/client_side_transport_timeouts_and

Comment by Tim Quinn [ 24/Feb/12 ]

Andreas,

When I asked earlier about the Java Web Start launch and the appclient launch, I meant the successful run of the client not just the initial launch.

Sorry for the confusion.

You asked whether this could be related to 15775. I am not sure. In that case the last
exception in the stack trace is quite different and originates from a different place in the code.

If you want to specify the properties that Harshad mentioned you can pass them on the URL to launch the app client:

http://host:port/path?prop=A=1&prop=B=2

would be equivalent to

java -DA=1 -DB=2 ...

on a normal java command line.

Comment by Tim Quinn [ 24/Feb/12 ]

Andreas,

I meant to ask about this earlier. You mentioned that if you look up the SLSB only once, lazily, (instead of multiple times)
and reuse the same reference then you do not get the errors.

Using multiple look-ups, which look-up causes the error? The first one? Second one? etc.

Also, you said that the look-ups occur in the main method. Can you attach the two versions of the main method to this issue:
the one that does multiple look-ups and the one that does a single lazy look-up with reuse? Or, of you'd prefer, you could e-mail
them to me directly (tjquinn at java dot net) and I would of course keep them confidential.

That might help us reproduce the problem here. Thanks.

Comment by Tim Quinn [ 24/Feb/12 ]

I have a very simple client that I use for various manual tests. I modified it to create a new InitialContext and then
use it to look up and use a stateless session bean.

It gave me the buffer timeout warning Andreas reported the first time I ran it using Java Web Start, but that did not
cause any class cast errors. And the next 7 times I ran it I saw no such warning.

(I will attach my Java Web Start trace file.) I ran the same client several times using the appclient command and
never saw the warning, but clearly that problem is intermittent so perhaps I was just lucky - or unlucky.

By the way, I did not notice any delay at all during the run with the error.

Comment by Tim Quinn [ 25/Feb/12 ]

Attached Java Web Start trace of app client launch with ORB warning...but it completed successfully.

Comment by andydr [ 26/Feb/12 ]

After a couple of code changes I assume the problem relates to
asynchronous ejb access. Our swing gui loads during startup
the data concurrently. Some EJBs are access from the main thread
and other EJBs via the awt-event queue.

I removed all new Thread(..) and SwingUtilitites.* parts and the startup
works as expected. Is concurrent access of ejbs not supported?

In a simple concurrent test I could reproduce the buffer timeout issue but
not the classcast problem:

for (int i = 0; i < 30; i++) {
   if (i % 2 == 0) {
     new Thread() {

       @Override
       public void run() {
         ... execute ejb
       }
     }.start();
   } else {
     ... execute ejb
   }
}
Comment by Tim Quinn [ 27/Feb/12 ]

Thanks for doing the additional investigation and posting your results.

The EJB itself on the server side is (if I remember the spec correctly) is threadsafe,
but the layers on the client side (the ORB particularly) could be a different matter entirely.

Harshad will know more, but from your findings it seems that using the same client-side
proxy from multiple threads is triggering the problem.

Comment by Tim Quinn [ 28/Feb/12 ]

based on the latest information from Andreas I have added to the title of this issue and am transferring it to the ORB component.

I am not sure whether this is a bug or whether the use of a single EJB proxy from multiple threads is unsupported, but Harshad is the right person to answer.





[GLASSFISH-18392] Multiple Failover of IIOP does not happen on dynamic cluster when one of the instances is removed Created: 22/Feb/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: rmi_iiop_failover
Affects Version/s: 3.1.2_dev
Fix Version/s: future release

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

OEL 5 + Oracle JDK


Attachments: Zip Archive instancedeleteMultipleFO.zip     File MultiEJBApp.ear    
Issue Links:
Dependency
depends on GLASSFISH-15804 Multiple failover not happening on OE... Resolved
Related
is related to GLASSFISH-15746 Multiple Failover of IIOP does not ha... Open

 Description   

We were investigating issue 15804 and by adding delays to the test operations (before and after start-cluster, killing instances, accessing business methods), the multiple-failover tests passing. But even with those delays, the multiple failover of IIOP still does not happen on dynamic cluster when one of the instances is removed. In those two tests, there are similarities (the same EJB application is used, multiple fail-over, same exception on client side). But there difference also in terms of testing steps. File this separate issue to track the new scenario.

Run test with appclient: appclient ... com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance MultipleFO
Exception was throw on client side:
[testng] javax.ejb.EJBException: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446344 Maybe; nested exception is:
[testng] org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at com.sun.appserver.ee.tests.ejb.stateful._SFSB3Remote_Wrapper.getName(com/sun/appserver/ee/tests/ejb/stateful/_SFSB3Remote_Wrapper.java)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.runTest2(Unknown Source)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.runMultipleFOTest(Unknown Source)
[testng] at com.sun.appserver.ee.tests.client.ClientDynamicClusterRemoveInstance.main(Unknown Source)
[testng] Caused by: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446344 Maybe; nested exception is:
[testng] org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:259)
[testng] at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
[testng] at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
[testng] at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
[testng] at com.sun.appserver.ee.tests.ejb.stateful._SFSB3Remote_Remote_DynamicStub.getName(com/sun/appserver/ee/tests/ejb/stateful/_SFSB3Remote_Remote_DynamicStub.java)
[testng] ... 4 more
[testng] Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe
[testng] at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown Source)
[testng] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[testng] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[testng] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[testng] at $Proxy32.connectionAbort(Unknown Source)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1537)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1084)
[testng] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
[testng] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
[testng] Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410030: Exception in a blocking read on connection SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/10.133.185.4:61556 remote=asqeopteron1.us.oracle.com/10.133.169.163:23703] ESTABLISHED true true] with a temporary selector vmcid: OMG minor code: 30 completed: No
[testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[testng] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[testng] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[testng] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[testng] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[testng] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[testng] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[testng] at $Proxy32.exceptionBlockingReadWithTemporarySelector(Unknown Source)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.blockingRead(SocketOrChannelConnectionImpl.java:1604)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1501)
[testng] ... 3 more
[testng] Caused by: java.io.IOException: Connection reset by peer
[testng] at sun.nio.ch.FileDispatcher.read0(Native Method)
[testng] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
[testng] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)
[testng] at sun.nio.ch.IOUtil.read(IOUtil.java:171)
[testng] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243)
[testng] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.blockingRead(SocketOrChannelConnectionImpl.java:1567)
[testng] ... 4 more

The steps to reproduce:

  1. Deploy MultiEJBApp.ear
  2. stop-cluster st-cluster
  3. start-instance instance110 and instance109
  4. access business methods
  5. Find and kill the instance with message [SFSB1Bean.getName]
  6. Delete the instance with message [SFSB1Bean.getName]
  7. start-cluster st-cluster
  8. access business methods
  9. Find and kill the instance with message [SFSB1Bean.getName] again.
  10. access more business methods
  11. assert the test pass or fail


 Comments   
Comment by mzh777 [ 22/Feb/12 ]

Test app and full test logs.





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

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.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/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1, 3.1_dev
Fix Version/s: 4.1.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: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1.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-16315] LAZY loading on attributes causes IOP00710285: (INTERNAL) A reflective tie got an error while invoking method ... Created: 05/Apr/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
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-16324] corba-orb-iiop-folb-devtest suite: two tests are failing Created: 06/Apr/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0
Fix Version/s: 4.1.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-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-16323] Fix FOLB related FindBugs issues in GlassFish repository Created: 06/Apr/11  Updated: 02/Jun/11

Status: In Progress
Project: glassfish
Component/s: rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: None
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 a number of FindBugs issues in code related to IIOP FOLB that need to be fixed:

kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:490: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:273: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:253: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:421: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.getAddressPortList(List) is never called
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:132: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.infoLog(String, Object[]) is never called
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialContext.java:238: NP_NULL_ON_SOME_PATH: Possible null pointer dereference of ? in new com.sun.enterprise.naming.impl.SerialContext(String, Hashtable, Habitat)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:292: DLS_DEAD_LOCAL_STORE: Dead store to provider in com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:283: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD: Write to static field com.sun.enterprise.naming.impl.SerialInitContextFactory.giso from instance method com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:271: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD: Write to static field com.sun.enterprise.naming.impl.SerialInitContextFactory.rrPolicy from instance method com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/TransientContext.java:744: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.TransientContext.print(Map) is never called

kcavanaugh: ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java:508: DLS_DEAD_LOCAL_STORE: Dead store to generatedRemoteIntf in com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(ClassLoader, String)
kcavanaugh: ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java:520: DLS_DEAD_LOCAL_STORE: Dead store to generatedRemoteWrapper in com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(ClassLoader, String)

kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java:153: ITA_INEFFICIENT_TO_ARRAY: Method org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(DataCollector, ORB) uses Collection.toArray() with zero-length array argument
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POAProtocolMgr.java:302: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from java.rmi.Remote to org.omg.CORBA.Object in org.glassfish.enterprise.iiop.impl.POAProtocolMgr.isIdentical(Remote, Remote)
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POAProtocolMgr.java:303: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from java.rmi.Remote to org.omg.CORBA.Object in org.glassfish.enterprise.iiop.impl.POAProtocolMgr.isIdentical(Remote, Remote)
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POARemoteReferenceFactory.java:543: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from org.omg.PortableServer.Servant to javax.rmi.CORBA.Tie in org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.postinvoke(byte[], POA, String, Object, Servant)

kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:79: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:123: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:134: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:142: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

kcavanaugh: security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/IIOPSSLUtilImpl.java:157: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from org.omg.PortableInterceptor.IORInfo to com.sun.corba.ee.spi.legacy.interceptor.IORInfoExt in com.sun.enterprise.iiop.security.IIOPSSLUtilImpl.createSSLTaggedComponent(IORInfo, Object)



 Comments   
Comment by Harshad Vilekar [ 20/May/11 ]

Updated:
trunk/v3/orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java

Fixed following issues:
#orb-connector-1 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:79:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-2 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:123:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-3 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:134:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-4 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:142:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
-----------------------

Updated trunk/v3/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java
Fixed following issue:
#orb-iiop-1 orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java:153:
ITA_INEFFICIENT_TO_ARRAY: Method org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(DataCollector,
ORB) uses Collection.toArray() with zero-length array argument
-----------------------

Comment by Harshad Vilekar [ 02/Jun/11 ]

Updated:
common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java

Fixed Following Issues:

1.1 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:490: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

1.2 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:273: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

1.3 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:253: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

2 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:421: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.getAddressPortList(List) is never called

3 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:132: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.infoLog(String, Object[]) is never called

Test Status:

  • Default build tests: PASS
  • web-ql, full-ql and ejb dev tests: PASS




[GLASSFISH-16164] eclipselink.weaving breaks marshalling out of the box Created: 05/Mar/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_dev
Fix Version/s: None

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

Windows 7 and Mac OS X


Attachments: Zip Archive TestCase.zip    
Issue Links:
Related
is related to GLASSFISH-17557 Odd deserialization fail Open
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, corba, eclipselink, orb-review

 Description   

Separately deployed EJB components that return @Entity objects, fail serialization and return empty objects to remote components (such as a managed bean in a separately deployed WAR). Adding: <property name="eclipselink.weaving" value="false"/> to persistence.xml fixes the issue, but cant be expected behavior out of the box. I tried 2 separate clean installs, and an upgrade from 3.0.1 but all have same broken behavior.

To reproduce:
1) Deploy EJB jar with a stateless EJB that returns an entity from remote interface.
2) Deploy web application with a managed bean that retrieves entity from injected EJB
3) Access managed bean from view.

I get empty entity classes (all fields null) with no errors in server.log.

I have a test case intellij project illustrating issue if required.



 Comments   
Comment by marina vatkina [ 07/Mar/11 ]

let's start with JPA

Comment by Mitesh Meswani [ 07/Mar/11 ]

Can you please attach the test project that you are mentioning above. That would help speed up things.

Comment by netricsoft [ 08/Mar/11 ]

Here is a video illustrating issue:

http://www.youtube.com/watch?v=2xg_QiGijuE

(watch in 'original' format)

The attached project assumes you have a jdbc resource jdbc/testcase setup with one table:

create table person (
id integer not null primary key,
email varchar2(80) not null
);

insert into person values ( 1, 'test@case.com' );

The test case contains 3 components/modules:

1) "Model", shared classes for Session and "Web" module.
Compile with EE 6.
2) "Session", an EJB component with a single EJB PeopleSessionBean. Compile with EE 6. This module contains the JPA persistence.xml WITHOUT the eclipselink.weaving property element. So it will not work until the following is added:
<properties>
<property name="eclipselink.weaving" value="false"/>
</properties>

3) "Web", a WAR component with a single managed bean that attempts to retrieve an entity from the remote EJB. Compile with EE 6 and Mojarra 2.1.

To reproduce issue:

Compile Model
Compile Session (include Model source)
Compile Web (include Model source)

Deploy Session component
Deploy Web component
Access web component (http://localhost/testcase/)

As is, you will get Id 0 and blank (null) for email.

Add <properties> element above to persistence-unit in persistence.xml, redeploy Session and Web and reload testcase page. You will get Id 1 and email test@case.com

Thanks

-jim

Comment by netricsoft [ 14/Mar/11 ]

Will this issue be fixed? or is this intended behavior?

thanks

Comment by Mitesh Meswani [ 14/Mar/11 ]

We are still investigating. Meanwhile, a workaround is to use attribute based persistence. The issue does not manifest there.

BTW, thanks for the reproductions and cool video walk through

Comment by Mitesh Meswani [ 07/Apr/11 ]

Ken,

Assigning to you to investigate why IIOP serialization layer causes this issue. I have sent you test app and instructions to reproduce this in email.

Comment by scatari [ 27/Jun/11 ]

Targeting for next release after 3.1.1.

Comment by Mitesh Meswani [ 20/Oct/11 ]

Another work around is adding property <property name="eclipselink.weaving.fetchgroups" value="false"/> to the persistence unit

Comment by jimmysklim [ 13/Dec/11 ]

Guys! Thank alot for the work around. After adding <property name="eclipselink.weaving.fetchgroups" value="false"/> it's worked.

Comment by jthoennes [ 22/Mar/12 ]

Any plans when this will be corrected?

Comment by kombatkuehn [ 27/Apr/12 ]

This issue still exists in 3.1.2 (build 23).

Comment by chrispy [ 14/Sep/12 ]

This bug is still a problem. When will this be fixed? A workaround is not a solution :-/

Comment by eldiegos [ 24/Sep/12 ]

OMG. This bug has been a pain on the neck until i found this issue. What a waste of time trying to solving it. Please glassfish team solve it.

I have vote for it.

Thanks.

Comment by vins4java [ 26/Feb/13 ]

I agree with eldiegos. I found this bug up to lastest 3.1.2.2 and there's no way to know if it will be fixed for glassfish 4.0 or not...
What's the plan for the resolution of this bug?

Comment by markokanala [ 07/Mar/13 ]

Has anyone tried if static weaving at the remote and calling side is a workaround ?

see http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance/Weaving/Static_Weaving

Comment by dmitriy.balakin [ 08/Mar/13 ]

I use eclipselink-staticweave-maven-plugin as a workaround.





[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-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: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_dev
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-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: 19/Dec/16

Status: In Progress
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
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-16492] NamingException when calling an EJB from one standalone instance to another Created: 28/Apr/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev, 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-20776] when new InitialContext ,the java.lang.NullPointerException is happenning Created: 22/Aug/13  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
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-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-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: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
Fix Version/s: 4.1.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: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
Fix Version/s: 4.1.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-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-19803] usage of internal proprietary API in appserver/orb/org-iiop Created: 08/Mar/13  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
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-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-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-19301] Enterprise Application client RMI connection to IIOP listener SSL fails with end of stream Created: 07/Nov/12  Updated: 06/Dec/12

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

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

Mac OS 10.6.8 Java 1.6.0_33



 Description   

G'day

If I ask my Enterprise Application Client to connect to Glassfish through the SSL IIOP listener the attempt fails with an end of stream exception in SocketOrChannelConnectionImpl reading input on port 3820.

I would like to secure the RMI communication between my Enterprise Application Client and Glassfish.

To do this I set -Dorg.omg.CORBA.ORBInitialPort=3820 in the Netbeans -> project properties -> Run -> VM options field of the application client. (Port 3820 is that of the SSL IIOP listener that does not require mutual authentication).

(I can only start the client through NetBeans because Java Web Start is broken for this application on this environment and the NetBeans generated distribution of the client is insufficiently complete to run stand alone.)

The stack trace is:

org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 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 $Proxy34.connectionAbort(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1537)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1084)
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.COMM_FAILURE: FINE: IOP00410011: IOException received when reading from connection SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/127.0.0.1:51164 remote=localhost/127.0.0.1:3820] ESTABLISHED true true] vmcid: OMG minor code: 11 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 $Proxy34.ioexceptionWhenReadingConnection(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:1708)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1481)
... 3 more
Caused by: java.io.IOException: End-of-stream
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:1700)
... 4 more
com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Remote ejb-ref name=com.CLTClient.client.CLTClient4/pingBean,Remote 3.x interface =com.CLT.remoteinterfaces.PingBean$PingBeanRemote,ejb-link=null,lookup=,mappedName=,jndi-name=com.CLT.remoteinterfaces.PingBean$PingBeanRemote,refType=Session into class com.CLTClient.client.CLTClient4: Lookup failed for 'java:comp/env/com.CLTClient.client.CLTClient4/pingBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:703)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:470)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:213)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:205)
at org.glassfish.appclient.client.acc.AppClientContainer$ClientMainClassSetting.getClientMainClass(AppClientContainer.java:625)
at org.glassfish.appclient.client.acc.AppClientContainer.getMainMethod(AppClientContainer.java:517)
at org.glassfish.appclient.client.acc.AppClientContainer.completePreparation(AppClientContainer.java:411)
at org.glassfish.appclient.client.acc.AppClientContainer.prepare(AppClientContainer.java:319)
at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:278)
at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:82)
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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/com.CLTClient.client.CLTClient4/pingBean' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=com.CLTClient.client.CLTClient4/pingBean,Remote 3.x interface =com.CLT.remoteinterfaces.PingBean$PingBeanRemote,ejb-link=null,lookup=,mappedName=,jndi-name=com.CLT.remoteinterfaces.PingBean$PingBeanRemote,refType=Session' . Actual (possibly internal) Remote JNDI name used for lookup is 'com.CLT.remoteinterfaces.PingBean$PingBeanRemote#com.CLT.remoteinterfaces.PingBean$PingBeanRemote' [Root exception is javax.naming.NamingException: Lookup failed for 'com.CLT.remoteinterfaces.PingBean$PingBeanRemote#com.CLT.remoteinterfaces.PingBean$PingBeanRemote' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl} [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe]]]]
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:392)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:599)
... 15 more
Caused by: javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=com.CLTClient.client.CLTClient4/pingBean,Remote 3.x interface =com.CLT.remoteinterfaces.PingBean$PingBeanRemote,ejb-link=null,lookup=,mappedName=,jndi-name=com.CLT.remoteinterfaces.PingBean$PingBeanRemote,refType=Session' . Actual (possibly internal) Remote JNDI name used for lookup is 'com.CLT.remoteinterfaces.PingBean$PingBeanRemote#com.CLT.remoteinterfaces.PingBean$PingBeanRemote' [Root exception is javax.naming.NamingException: Lookup failed for 'com.CLT.remoteinterfaces.PingBean$PingBeanRemote#com.CLT.remoteinterfaces.PingBean$PingBeanRemote' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl} [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe]]]
at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:191)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:1109)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:776)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:744)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:169)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
... 18 more
Caused by: javax.naming.NamingException: Lookup failed for 'com.CLT.remoteinterfaces.PingBean$PingBeanRemote#com.CLT.remoteinterfaces.PingBean$PingBeanRemote' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl} [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe]]
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:392)
at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:186)
... 23 more
Caused by: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 completed: Maybe]
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:351)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:504)
... 26 more
Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410008: Connection abort vmcid: OMG minor code: 8 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 $Proxy34.connectionAbort(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1537)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1084)
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.COMM_FAILURE: FINE: IOP00410011: IOException received when reading from connection SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/127.0.0.1:51164 remote=localhost/127.0.0.1:3820] ESTABLISHED true true] vmcid: OMG minor code: 11 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 $Proxy34.ioexceptionWhenReadingConnection(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:1708)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1481)
... 3 more
Caused by: java.io.IOException: End-of-stream
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:1700)
... 4 more
Java Result: 1






[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: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
Fix Version/s: 4.1.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-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 ]

Do you have different (2.x vs. 3.x) GF versions? I've never seen problems like this before.

Comment by marina vatkina [ 15/Aug/12 ]

Assigning to ORB for the initial investigation.

Comment by gray [ 15/Aug/12 ]

I checked source code repository for as old version of Glassfish as I can reach - seems like this IDs had this values from very beginning. You will not see this ClassNotFound exceptions until set javax.enterprise.resource.corba and javax.enterprise.resource.iiop log level to FINEST (or may be FINER would be enough). This exceptions actually prevents normal execution (or may just hide real problem) of "request_synchronization" and other methods on remote JCoordinator object during distributed transation.

If your question was about versions of Glassfish instances I am using? Then - answer is No. This is actually two standalone instances of glassfish 3.1.2.2 under same domain and even residing on same machine (under different CONFIG nodes however). This is just test environment - real production system will be distributed (i.e. instances will be on different hosts).

Comment by gray [ 17/Aug/12 ]

So? Any news?

Comment by gray [ 23/Aug/12 ]

Ping.

Comment by Harshad Vilekar [ 23/Aug/12 ]

Do you see any different behavior if SSL is not in the picture ? Could you please attach a simple test that can demonstrate the problem ?

Comment by gray [ 24/Aug/12 ]

I've pointed exact place in source code where exception is, and exact reason why it is happening. If you check logic of classes and methods you clearly will see the problem. I've patched my instance of glassfish (changed constant values in generated classes inside com.sun.jts.codegen.jtsxa and com.sun.jts.codegen.otsidl packages) and problem disappeared. This problem have nothing to do with SSL - it is only happen when you have distributed transaction involved, i.e. it works over SSL if ejb method called outside transaction scope. If you look closely at code excerpt above you'll see that if catches all exceptions that may happen in createStubFactory method and basically ignore them.
I'll try to create "simple example" but I don't think that this worth effort because we know exactly what is the problem and how to fix it.

Comment by gray [ 24/Aug/12 ]
...
Caused by: java.lang.ClassNotFoundException: otsidl.JCoordinator (no security manager: RMI class loader disabled)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:394)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:184)
	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:219)
	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:152)
	at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:319)
	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.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:73)
	... 23 more
...
Comment by gray [ 24/Aug/12 ]

I've checked - same error without ssl.





[GLASSFISH-18771] [PERF] Remote EJB lookups are slow due to repeated class loading Created: 31/May/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.1.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-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-18723] [PERF]Excessive thread contention in orb code Created: 13/May/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: orb