This issue tracks failing devtests from Corba test-all build target. Failing scenarios are excluded from the test. Please re-include when fixed.

• corba.folb.FolbTest:
  ClientMulti, ClientCircular, ClientWaitTimeout

• corba.folb_8_1.FolbTest:
  ClientForTiming_NoFs_NoF_NoC, ClientForTiming_Fs_NoF_NoC, ClientForTiming_Fs_NoF_C, ClientForTiming_Fs_F_NoC, ClientForTiming_Fs_F_C

• Note: Other FolbTest scenarios PASS.

Affected Versions

[current]

This involves verifying following scenarios:

• Java client to access EJB remote deployed on GlassFish behind a NAT (see http://java.net/jira/browse/GLASSFISH-17151)
• Java client to access EJB remote deployed on GlassFish behind a NAT - with SSL IIOP (see http://kenai.com/jira/browse/GF_CORBA_V3_MIRROR-4)
• App Client to access EJB remote deployed on GlassFish behind a NAT (see http://java.net/jira/browse/GLASSFISH-17147)

This is a place holder issue for Pull request from javaee/glassfish-corba#23

This is a place holder issue for Pull request from javaee/glassfish-corba#22

Hi,

I'm using NetBeans RCP to build a standalone J2EE application, that talks with
remote EJBs deployed into a glassfish server.

I'm getting the exception below (ClassNotFound,
com.sun.ejb.containers.GenericEJBHome).

I think the problem is related to the way NetBeans uses classloaders internally.

I wonder if it would be possible for you to use a
"Thread.currentThread().getContextClassLoader()" when dinamically creating
remote ejb stubs/skeletons so that remote EJB classes can be loaded correctly.

I've submitted an issue to the NetBeans team on this:

http://www.netbeans.org/issues/show_bug.cgi?id=151368

(there's a test case there)

I think that it's important to be able to access remote EJBs from within
NetBeans RCP applications, as NetBeans RCP is the best architecture out there to
build complex Swing applications.

Environment

Operating System: All
Platform: All

Affected Versions

[current]

Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.

• Start Release Review
• Update Release Review Tracker

Additional information:

• How to submit a release review
• Eclipse Handbook

This bug has been reported on JDK some time ago:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504275

The java code generated from an idl union where the switch is the boolean type
will not compile with javac. The following example IDL will compile java code
with idlj, but when we run the java code through javac it fails with syntax
errors.
--- example IDL follows --------------
module xyz
{
union LongTypeOpt switch (boolean) {
case TRUE: long value;
};

};

A fix is available for JDK:
https://www.programcreek.com/java-api-examples/?code=jboss/openjdk-orb/openjdk-orb-master/src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/UnionGen.java

look at:
private void writeVerifyDefault()
{
...
if (Util.javaName(utype).equals ("boolean")) {
...
}
...
}

When setting TCP timeouts per this article:
http://blogs.sun.com/ejcorba/entry/more_on_tcp_timeouts_in

By setting the setting the System property:
-Dcom.sun.corba.ee.transport.ORBTCPTimeouts=500:30000:20

Glassfish ORB throws an exception saying that the timeouts need to "3 positive
decimal integers separated by :"

I traced this exception down to line #61 in TcpTimeoutsImpl
(http://mercurial2.foundry.sun.com/corba/corba-gfv2-master/file/0fc818f2f9e5/src/share/classes/com/sun/corba/se/impl/transport/TcpTimeoutsImpl.java)

The conditional states:
if ((data.length <= 3) || (data.length > 4))

I think the '(data.length <= 3)' should be '(data.length < 3)' to allow for 3 or
4 arguments.

Environment

Operating System: All
Platform: All

orbmain/src/main/java/com/sun/corba/ee/impl/transport/ByteBufferPoolImpl.java

The "while"-loop near start of ByteBufferPoolImpl.reAllocate() doubling the size until it is large enough may turn into an infinite loop, if the minimumSize parameter is ever more than 1 GB. Probably not the most common situation, but if it ever happened, then going into a tight busy loop surely isn't what anyone would want.

Not sure, how to best solve it, though. Maybe also check for size < 0, or use a long-typed helper variable just within the loop ...

This task is for creating a basic build CI/CD pipeline for this project on Eclipse infrastructure. More information is here: https://ci.eclipse.org/.

The pfl-test component is not needed by the orb production code, but it is included in its dependency list.

maven-compiler-plugin is managed as dependency, but used as [unmanaged, unversioned] plugin. It causes following, due to unspecified version on use by child modules:

[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.glassfish.corba:exception-annotation-processor:jar:4.2.1-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 44, column 21
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.glassfish.corba:glassfish-corba-tests:pom:4.2.1-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 182, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

This task is for creating a project release CI/CD pipeline.

Use these documents as a reference:

• How to release the first Eclipse version of projects
• JSONP release job

This is a place holder issue for Pull request from javaee/glassfish-corba#21

Add code coverage & reporting to Maven

GlassFish is looking for an alternative rmic due to the removal of tools.jar from Java 11 by JEP 220*.
*) https://openjdk.java.net/jeps/220

It appears that orb has its own rmic implementation, would it be possible to publish that as an osgi module?

If possible, I have already verified that GlassFish can reference orb's rmic by making the following modifications to orb and GlassFish:

orb side: hs536@f78d5e5
GlassFish side: hs536/glassfish@6da9614

Can this code be fixed RepositoryId.java#L1000?
Method convertFromISOLatin1 doesn't correctly decodes id encoded by convertToISOLatin1 in case of multibyte values.

This issue was unavailable for migration from original issue tracker.

The old Unsafe.defineClass() method is no longer available in JDK11. Instead, we need to use

org.glassfish.pfl.basic.reflection.Bridge.defineClass(Class,String,byte[])

which uses the new supported means of defining a class, given a class in the same package and protection domain.

The gmbal API call in ORB

mom = ManagedObjectManagerFactory.createFederated(MONITORING_SERVER);

is causing a large number of gmbal instances to be created and is affecting GlassFish performance. See http://java.net/jira/browse/GLASSFISH-17044.
Attached is the call stack.

This fix should be to defer the gmbal API calls until there is a JMX client connection.

From Naman: JMX service would start on 8686 (on DAS). So you can check localhost:8686 for the same. From quicklook workspace you can find the sample for the same.

In GlassFish monitoring (StatsProviderManagerDelegateImpl), we defer the gmbal API calls by extending MBeanListener.CallbackImpl and overriding mbeanRegistered method. This method is called when AMX DomainRoot is loaded (when there is a JMX, for example). AMX DomainRoot needs to be ready before any other mbeans can be registered.

Fix should be targeted for GlassFish 3.1.2.

Convert build to Maven

It should now be "oss-release"

As noted in section 1.5 of the serialization spec https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250:

"By using serialPersistentFields to define the Serializable fields for a class, there no longer is a limitation that a serializable field must be a field within the current definition of the Serializable class. The writeObject and readObject methods of the Serializable class can map the current implementation of the class to the serializable fields of the class using the interface that is described in Section 1.7, "Accessing Serializable Fields of a Class." Therefore, the fields for a Serializable class can change in a later release, as long as it maintains the mapping back to its Serializable fields that must remain compatible across release boundaries."

But the code is checking that all values in serialPersistentFields are fields in the class, which is incorrect.

The glassfish-corba-orb Maven artifact in version 4.2.1 has transitive org.glassfish.pfl dependencies to both version 4.1.0 and 4.0.1 on different dependency paths.

I assume that 4.1.0 should be used at runtime?

The dependency convergence rule of Maven Enforcer Plugin (https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html) reports:

[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ test ---
[WARNING] 
Dependency convergence error for org.glassfish.pfl:pfl-basic:4.1.0 paths to dependency are:
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.corba:glassfish-corba-internal-api:4.2.1
      +-org.glassfish.pfl:pfl-basic:4.1.0
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.corba:exception-annotation-processor:4.2.1
      +-org.glassfish.pfl:pfl-basic:4.1.0
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.gmbal:gmbal:4.0.0
      +-org.glassfish.pfl:pfl-basic:4.0.1
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.gmbal:gmbal:4.0.0
      +-org.glassfish.pfl:pfl-basic-tools:4.0.1
        +-org.glassfish.pfl:pfl-basic:4.0.1
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.pfl:pfl-basic:4.1.0
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.pfl:pfl-dynamic:4.1.0
      +-org.glassfish.pfl:pfl-basic:4.1.0

[WARNING] 
Dependency convergence error for org.glassfish.pfl:pfl-tf:4.0.1 paths to dependency are:
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.gmbal:gmbal:4.0.0
      +-org.glassfish.pfl:pfl-tf:4.0.1
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.gmbal:gmbal:4.0.0
      +-org.glassfish.pfl:pfl-tf-tools:4.0.1
        +-org.glassfish.pfl:pfl-tf:4.0.1
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.pfl:pfl-tf:4.1.0

[WARNING] 
Dependency convergence error for org.glassfish.pfl:pfl-asm:4.0.1 paths to dependency are:
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.gmbal:gmbal:4.0.0
      +-org.glassfish.pfl:pfl-tf-tools:4.0.1
        +-org.glassfish.pfl:pfl-asm:4.0.1
and
+-test:test:1.0.3-SNAPSHOT
  +-org.glassfish.corba:glassfish-corba-orb:4.2.1
    +-org.glassfish.pfl:pfl-dynamic:4.1.0
      +-org.glassfish.pfl:pfl-asm:4.1.0

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
Failed while enforcing releasability. See above detailed error message.

In 4.2.1 the class loader to generate stubs has been changed from the context class loader to that of the one for which the stub is generated:

public Class<?> create( ProtectionDomain pd, ClassLoader cl,
        boolean debug, PrintStream ps ) {

        Pair<String,String> nm = splitClassName( className ) ;

        _clear() ;
        _setClassLoader( cl ) ;

vs

public Class<?> create( Class<?> anchorClass,
         boolean debug, PrintStream ps ) {

          Pair<String,String> nm = splitClassName( className ) ;

          _clear() ;
         _setClassLoader( anchorClass.getClassLoader() ) ;

See 471b980#diff-9cebdcf343a6c675195053fd3449dbcaR197

The effect is that the PFL code (org.glassfish.pfl.dynamic.codegen.spi.Type) called later may not have access to a lot of types needed. For instance javax.rmi.CORBA.Stub if the bundle for which the proxy/stub happens to be generated doesn't have this imported. This results in errors like e.g.:

Class 'javax.rmi.CORBA.Stub' was not found because bundle 
    org.glassfish.main.common.glassfish-naming [243] 
does not import 
    'javax.rmi.CORBA' 
even though bundle 
     org.glassfish.corba.glassfish-corba-omgapi [45] {
         bundle-symbolic-name=org.glassfish.corba.glassfish-corba-omgapi, 
         bundle-version=4.2.1, 
         version=1.0.0, 
         osgi.wiring.package=javax.rmi.CORBA} 
does export it. 
           
Additionally, the class is also available from the system class loader. 
           
There are two fixes: 
 
1) Add an import for 'javax.rmi.CORBA' to bundle org.glassfish.main.common.glassfish-naming [243]; imports are necessary for each class directly touched by bundle code or indirectly touched, such as super classes if their methods are used. 
                       
2) Add package 'javax.rmi.CORBA' to the 'org.osgi.framework.bootdelegation' property; a library or VM bug can cause classes to be loaded by the wrong class loader. 
                               
The first approach is preferable for preserving modularity. ***

In 4.2.0 the context class loader would be used, which would have the following chain:

 BundleImpl.loadClass(String) line: 958 --> GlassFish-Application-Common-Module [109]
 OSGiModuleImpl$4$1.run() line: 408	
 OSGiModuleImpl$4$1.run() line: 405	
 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method]	
 OSGiModuleImpl$4.loadClass(String, boolean) line: 405	
 OSGiModuleImpl$4(ClassLoader).loadClass(String) line: 357	
 APIClassLoaderServiceImpl$APIClassLoader.loadClass(String, boolean) line: 214	
 URLClassLoader(ClassLoader).loadClass(String, boolean) line: 411	
 DelegatingClassLoader(ClassLoader).loadClass(String, boolean) line: 411	
 ASURLClassLoader(ClassLoader).loadClass(String, boolean) line: 411

GlassFish-Application-Common-Module is capable of loading 'javax.rmi.CORBA', but also to load classes that come from other bundles, such as com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase

Note that the class loader in PFL is used e.g. here:

public Class<?> getTypeClass() {
    if (typeClass == null) {
        try {
            typeClass = Class.forName( name, true, CurrentClassLoader.get() ) ;
        } catch (ClassNotFoundException cnfe) {
            IllegalArgumentException exc = 
                new IllegalArgumentException( 
                    "Cannot load class for type " + name ) ;
                    exc.initCause( cnfe ) ;
                    throw exc ;
        }
        // [...]
}

cc @hs536 @m0mus

with corba removal from jdk11, there is currently no clean way to use this implementation on within OSGi framework running on JDK 11. The problem is that package 'javax.rmi' is not exported by glassfish-corba-omgapi, so it is not possible to call 'javax.rmi.PortableRemoteObject.narrow' within OSGi environment when using this library

Failure is seen in https://jira.oraclecorp.com/jira/browse/OWLS-50834

If "Request Meaaage" that is more than the number of threads in "thread-pool-1" is sent to the IJServer cluster,
all pooled threads wait for "Fragment Message" to be processed and become time-outs.

**LOG**javax.ejb.EJBException: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446361 No; nested exception is: 
	org.omg.CORBA.COMM_FAILURE: WARNING: 00410025: Write of message exceeded TCP timeout : max wait time = 6,000 ms, total time spent blocked, waiting to write = 7,280 ms.  vmcid: OMG  minor code: 25  completed: No
javax.ejb.EJBException: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446361 No; nested exception is: 
	org.omg.CORBA.COMM_FAILURE: WARNING: 00410025: Write of message exceeded TCP timeout : max wait time = 6,000 ms, total time spent blocked, waiting to write = 7,280 ms.  vmcid: OMG  minor code: 25  completed: No
	at com.fujitsu.test.ejb._DataTest_Wrapper.sendData(com/fujitsu/test/ejb/_DataTest_Wrapper.java)
	at datatestacc.InnerThread_loop1.run(Main.java:66)
Caused by: java.rmi.MarshalException: CORBA COMM_FAILURE 1330446361 No; nested exception is: 
	org.omg.CORBA.COMM_FAILURE: WARNING: 00410025: Write of message exceeded TCP timeout : max wait time = 6,000 ms, total time spent blocked, waiting to write = 7,280 ms.  vmcid: OMG  minor code: 25  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:226)
	at com.fujitsu.test.ejb.__DataTest_Remote_DynamicStub.sendData(com/fujitsu/test/ejb/__DataTest_Remote_DynamicStub.java)
	... 2 more
Caused by: org.omg.CORBA.COMM_FAILURE: WARNING: 00410025: Write of message exceeded TCP timeout : max wait time = 6,000 ms, total time spent blocked, waiting to write = 7,280 ms.  vmcid: OMG  minor code: 25  completed: No
	at com.sun.proxy.$Proxy36.transportWriteTimeoutExceeded(Unknown Source)
	at com.sun.corba.ee.impl.transport.NioBufferWriter.write(NioBufferWriter.java:62)
	at com.sun.corba.ee.impl.transport.ConnectionImpl.writeUsingNio(ConnectionImpl.java:508)
	at com.sun.corba.ee.impl.transport.ConnectionImpl.write(ConnectionImpl.java:480)
	at com.sun.corba.ee.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:225)
	at com.sun.corba.ee.impl.transport.ConnectionImpl.sendHelper(ConnectionImpl.java:1153)
	at com.sun.corba.ee.impl.transport.ConnectionImpl.sendCancelRequest(ConnectionImpl.java:1142)
	at com.sun.corba.ee.impl.transport.ConnectionImpl.sendCancelRequestWithLock(ConnectionImpl.java:1162)
	at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(MessageMediatorImpl.java:373)
	at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.endRequest(ClientRequestDispatcherImpl.java:916)
	at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.releaseReply(ClientDelegateImpl.java:279)
	at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:208)
	... 5 more

To operate even in this case, I propose the following corrections.

(1) The thread pool for the thread that processes "Fragment Message" is prepared.
ex) "fragment-thread-pool"

(2) Received "Fragment Message" is processed by the thread pooled by (1).

**glassfish-corba/orbmain/src/main/java/com/sun/corba/ee/impl/protocol/giopmsgheaders/MessageBase.java**
    public static MessageBase parseGiopHeader(ORB orb,
              Connection connection,
              ByteBuffer buf,
              int startPosition) {
        ...

        //
        // Initialize the generic GIOP header instance variables.
        // 
        if ((it[4] == 0x01) && (it[5] == 0x00)) { // 1.0
            Message_1_0 msg10 = (Message_1_0) msg;
            msg10.magic = magic;
            msg10.GIOP_version = new GIOPVersion(it[4], it[5]);
            msg10.byte_order = (it[6] == LITTLE_ENDIAN_BIT);
            // 'request partitioning' not supported on GIOP version 1.0
            // so just use the default thread pool, 0.
            msg.threadPoolToUse = 0;
            msg10.message_type = it[7];
            msg10.message_size = readSize(it[8], it[9], it[10], it[11],
    msg10.isLittleEndian()) +
    GIOPMessageHeaderLength;
        } else { // 1.1 & 1.2
            Message_1_1 msg11 = (Message_1_1) msg;
            msg11.magic = magic;
            msg11.GIOP_version = new GIOPVersion(it[4], it[5]);
            msg11.flags = (byte) (it[6] & TRAILING_TWO_BIT_BYTE_MASK);
            // IMPORTANT: For 'request partitioning', the thread pool to use
            //            information is stored in the leading 6 bits of byte 6.
            //
            // IMPORTANT: Request partitioning is a PROPRIETARY EXTENSION !!!
            //
            // NOTE: Bitwise operators will promote a byte to an int before 
            //       performing a bitwise operation and bytes, ints, longs, etc
            //       are signed types in Java. Thus, the need for the 
            //       THREAD_POOL_TO_USE_MASK operation.
            if(it[7] == GIOPFragment){           // add
msg.threadPoolToUse = orb.getThreadPoolManager().getThreadPoolNumericId("fragment-thread-pool"); // add
            } else{
msg.threadPoolToUse = (it[6] >>> 2) & THREAD_POOL_TO_USE_MASK;
            }
            msg11.message_type = it[7];

        ...

We ask for your kind consideration.

Attached is a patch that fixes a NullPointerException when invoking an
operation with empty param list via a typed mxbean proxy (and unit test for
duplicating issue)

I want to use the com.sun.jndi.cosnaming.CNCtxFactory on JDK 11+.

GlassFish 4.1 has a severe performance regression from GlassFish 4.0.

See Payara issue for detailed analysis and a fix

payara/Payara#251

Environment

GlassFish 4.1

We are trying to use the Glassfish ORB (version 4.2.0-b003) with SSLSockets, by setting the com.sun.corba.ee.legacy.connection.ORBSocketFactoryClass property to an according custom factory. This leads to a problem on the client side. As a matter of fact, an SSLSocket has no SocketChannel. For sockets without a channel the ORB sets the useSelectThreadToWait flag to false (com.sun.corba.ee.impl.transport.ConnectionImpl#defineSocket). This causes the creation of an extra thread that blocks our main thread:

"main" #1 prio=5 os_prio=0 cpu=2423,90ms elapsed=42,16s tid=0x00007f9a50017000 nid=0x4698 waiting for monitor entry [0x00007f9a58aa5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.security.ssl.SSLSocketImpl.getOutputStream(java.base@11-ea/SSLSocketImpl.java:667)
- waiting to lock <0x00000000e31f7718> (a sun.security.ssl.SSLSocketImpl)
at com.sun.corba.ee.impl.transport.ConnectionImpl.write(ConnectionImpl.java:487)
at com.sun.corba.ee.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:225)
at com.sun.corba.ee.impl.transport.ConnectionImpl.sendWithoutLock(ConnectionImpl.java:758)
at com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:146)
at com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendMessage(BufferManagerWriteStream.java:160)
at com.sun.corba.ee.impl.encoding.CDROutputObject.finishSendingMessage(CDROutputObject.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.finishSendingRequest(MessageMediatorImpl.java:254)
at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.marshalingComplete1(ClientRequestDispatcherImpl.java:398)
at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.marshalingComplete(ClientRequestDispatcherImpl.java:365)
at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.invoke(ClientDelegateImpl.java:259)
at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:491)
[...]
at org.example.OurClientApplication.main(OurClientApplication.java:354)

"p: default-threadpool; w: 1" #24 daemon prio=5 os_prio=0 cpu=1,87ms elapsed=39,39s tid=0x00007f9a51cac800 nid=0x46c4 runnable [0x00007f99a251d000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(java.base@11-ea/Native Method)
at java.net.SocketInputStream.socketRead(java.base@11-ea/SocketInputStream.java:115)
at java.net.SocketInputStream.read(java.base@11-ea/SocketInputStream.java:168)
at java.net.SocketInputStream.read(java.base@11-ea/SocketInputStream.java:140)
at sun.security.ssl.SSLSocketInputRecord.read(java.base@11-ea/SSLSocketInputRecord.java:464)
at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base@11-ea/SSLSocketInputRecord.java:70)
at sun.security.ssl.SSLSocketImpl.readRecord(java.base@11-ea/SSLSocketImpl.java:839)
- locked <0x00000000e31f7718> (a sun.security.ssl.SSLSocketImpl)
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11-ea/SSLSocketImpl.java:602)
- locked <0x00000000e2f47a18> (a sun.security.ssl.SSLSocketImpl$AppInputStream)
at com.sun.corba.ee.impl.transport.ConnectionImpl.readFully(ConnectionImpl.java:461)
at com.sun.corba.ee.impl.transport.ConnectionImpl.read(ConnectionImpl.java:421)
at com.sun.corba.ee.impl.transport.ConnectionImpl.createMessageMediator(ConnectionImpl.java:382)
at com.sun.corba.ee.impl.transport.ConnectionImpl.readBits(ConnectionImpl.java:332)
at com.sun.corba.ee.impl.transport.ConnectionImpl.read(ConnectionImpl.java:324)
at com.sun.corba.ee.impl.transport.ReaderThreadImpl.doWork(ReaderThreadImpl.java:113)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)

In this state, our application hangs forever.

We can reproduce this effect even easier, without a custom socket factory, just by setting com.sun.corba.ee.transport.ORBUseNIOSelectToWait to false.

idlj from glassfish-corba-orb 4.2.0-b004 creates wrong repository id.
Looks like a regression as it has been fixed (several times) before in openjdk idlj, see https://bugs.openjdk.java.net/browse/JDK-6438259

I have recently upgradet from Glassfish 3.0.1 to Glassfish 3.1.2.2 on a client-server application using EJB. As it is part of a closed intranet, SSL is not used for the communication between the client and server.

To upgrade to a new Glassfish version, I just basically copied the setup of the old glassfish-server, page by page. Still, when I tried to do a login against the server, it repeatedly failed due to CORBA NO PERMISSION errors. After a bit of debugging, I found that it was due to the server having SSL required, and when the client tried to connect without SSL, it failed due to mismatch in this respect.

The way it is determined whether the server requires SSL is in the SecurityMechanismSelector class. Here, in the postConstruct method, a (actually 2) EjbIORConfigurationDescriptor are made. This object holds values describing whether SSL is required on the server or not. These values default to SUPPORTED, but if the property "com.sun.CSIV2.ssl.server.required" (orbHelper.getCSIv2Props()).getProperty(GlassFishORBHelper.ORB_SSL_SERVER_REQUIRED) is set to true, it will override a couple of values regarding SSL to REQUIRED. The value of the property is set in the GlassFishORBManager class, and it is based on the iiop-connectors of the server (method initProperties). What it basically does to find this out is to loop through the iiop connectors, and check if they have an SSL-element. If there is one connector that does not have an SSL-element, SSL is not required, if all have it SSL is required.

The problem with this is that per default, all connectors (even the orb-listener-1) have an SSL-element in their domain.xml-representation. I've tried simply removing the SSL-element of the orb-listener-1 from the domain.xml, and then authentication works just fine. But, if I in the admin console enter the SSL-tab of this listener, it will create the SSL-element again. So, it's not a very robust solution to the problem.

Whether or not SSL is required should be specified in a different way, so that one does not need to hack the domain.xml in order to have ORB-communication without SSL, nor need to worry that someone will enter the wrong page in the admin console and mess everything up.

Environment

Glassfish 3.1.2.2

Affected Versions

[current]

Running GF Quicklook with JDK7U25 or later causes a test failure:
[testng] ===============================================
[testng] ejb_remoteview
[testng] Tests run: 3, Failures: 1, Skips: 2
[testng] ===============================================

To reproduce:
1. Unzip glassfish.zip from GF 4.0.1 (I assume GF 4.0 would fail too).
2. Remove the temporary workaround from the GF domain.xml file:
-Djdk.corba.allowOutputStreamSubclass=true
3. Run quicklook tests with JDK7U25 or later.

Quicklook output:

[testng] javax.naming.NamingException: Lookup failed for 'java:global/remoteview/HelloBean!remoteview.HelloHome' in Se
rialContext[myEnv=

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

[Root exception is javax.naming.NameNotFoundException: HelloBean!remoteview.HelloHome not found]
[testng] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
[testng] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
[testng] at javax.naming.InitialContext.lookup(InitialContext.java:411)
[testng] at test.ejb.remoteview.RemoteViewTestNG.helloRemote(RemoteViewTestNG.java:58)
[testng] Caused by: javax.naming.NameNotFoundException: HelloBean!remoteview.HelloHome not found
[testng] at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
[testng] at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
[testng] at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
[testng] at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
[testng] at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
[testng] at com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.
java:109)
[testng] at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
[testng] at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
[testng] at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherIm
pl.java:528)
[testng] at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:1
99)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
[testng] at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
[testng] at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
[testng] at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
[testng] at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
[testng] ... Removed 26 stack frames
[testng] SKIPPED: nonPortableGlobal
[testng] SKIPPED: portableGlobal
[testng]

server.log output:

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

Here is some mail from the JDK sust team about changes to JDK7U25

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

See following for references :

CCC request : http://ccc.us.oracle.com/8004625
Bug DB report : might not be visible if you can't view vulnerabilities :

https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=14127656

changesets :
src change : http://closedjdk.us.oracle.com/jdk7u/jdk7u25/corba/rev/161ec4dd450d
test case : http://closedjdk.us.oracle.com/jdk7u/jdk7u25/jdk/test/closed/rev/44ba7a614c1e

As per CCC, there is a property flag is allow subclass instantiations without the security check (jdk.corba.allowOutputStreamSubclass=true)

We have added this property to the GF domain.xml file (domain.xml) as a temporary workaround to get QL to pass with JDK7U25 and JDK7U40.
-Djdk.corba.allowOutputStreamSubclass=true

When this issue is resolved, PLEASE remove those lines from the domain.xml file.

Environment

solaris, linux, mac, windows

Glassfish threads can hang in an endless loop. This is cause by a bogus exit condition:

{{
// in acquireLock:
do
{
...
try

{ ... // invokation of a function which detects thread interruption and throws InterruptedException }

catch(InterruptedException exc)

{ interrupted = true; }

if(interrupted)
Thread.currentThread().interrupt();
} while(true);
}}

If the current thread the InterruptedException is caught but does not break the loop.

=> 100% load for the thread. You can end up with many threads and thus all CPUs at 100%.

suggested fix: don't catch the InterruptedException. Only catch an Exception if you can handle it properly. (here it's not handly properly, catching an InterruptedException to interrupt() again is simply nonsens.)

Environment

any

Affected Versions

[current]

https://kenai.com/projects/gf-corba-v3-mirror/sources/gfv2-master/revision/28

• Added a poll in requestWork to avoid a lost event problem. Critical fix for Ericsson.
  As a result, this bug is fixed as follows.

• if (System.currentTimeMillis() >= timeOutTime) {

  • // Protect against case where isQueueEmpty() is false, and
  • // adding work to the queue woke up a waiting worker, but
  • // then the time check caused the awakened thread to exit.
  • if (this.isQueueEmpty() && System.currentTimeMillis() >= timeOutTime) {

The above-mentioned bug-fix is included in latest glassfish.
https://hg.java.net/hg/glassfish-corba~hg/rev/7014b5cd2039

• Brought over Ericsson concurrency improvements from GF 2.1.

This bug-fix is used to judge that Wake up occurred when Wake up and
the time-out occur at the same time by RequestWork.
However, the way of this correction judged by the isQueueEmpty() function was wrong.

When Queue.size() function returns 1, and Wake up and the time-out occur
at the same time, the task in the queue is not executed until the Execution of the next task is requested.

Because when becoming a time-out, availableThreads is sure to become 1 or more.
In a word, when the return value of the queue.size() function is 1,
the return value of the isQueueEmpty() function always becomes True.

Therefore, because the thread is deleted when 0 is set to minThreads, the task in the queue is not executed.

It is necessary to judge whether there is a task that should execute it by requestWork is the return value of Queue.size() function is 0.

if (queue.size() == 0 && System.currentTimeMillis() >= timeOutTime) {

In addition, we believe that "isQueueEmpty" is not an appropriate method name.
Please consider a change in the method name.

We ask for your kind consideration.

as is required and documented in https://www.eclipse.org/projects/handbook/#legaldoc

This is a place holder issue for Pull request from javaee/glassfish-corba#24

The handling of requests and responses uses a simulation of blocked I/O on top of NIO calls in order to preserve the old code structure; this needs to be cleaned up to take advantage of Grizzly NIO handling.

We are using idlj (version 3.2) to generate java files. The Helper classes use Double-checked locking for the type() which can be unsafe.

Our fix right now is to modify the code after idlj has done it's job, would it be possible to have it generate different code?

(Am I even creating a case in the correct project)

Example of the generated code is:
private static org.omg.CORBA.TypeCode __typeCode = null;
private static boolean __active = false;
synchronized public static org.omg.CORBA.TypeCode type ()
{
if (__typeCode == null)
{
synchronized (org.omg.CORBA.TypeCode.class)
{
if (__typeCode == null)
{
if (__active)

{ return org.omg.CORBA.ORB.init().create_recursive_tc ( _id ); }

__active = true;
....

Environment

w7-vs2010-64
IDL-to-Java compiler (portable), version "3.2"

We have a time tracker application where clients connect to GFv3.1 over IIOP on VPN. The client connects to the EJB server every 90 seconds. when the client is put to sleep and reawakened, it is unable to connect to the server and has to be restarted, which is unacceptable. The previous version of our application ran on JBoss 4.2 and we never experienced any problems there.

To reproduce:

• Deploy attached EAR file on GFv3.1 and run unit test LookupTest.testSleep(). It will connect every 30 sec. to a very simple session bean
• then put the computer to sleep and wake it up after a few minutes

You will see the following output:

Starting round 1
Tue Feb 22 20:59:11 CET 2011 - Response from server: Hello from Session Bean 2, took: 7982ms.
Starting round 2
Tue Feb 22 20:59:42 CET 2011 - Response from server: Hello from Session Bean 2, took: 914ms.
Starting round 3
Tue Feb 22 21:00:13 CET 2011 - Response from server: Hello from Session Bean 2, took: 894ms.
Starting round 4
Feb 22, 2011 9:33:28 PM com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
WARNING: IOP00410019: Communications timeout waiting for response. Exceeded 1,800,000 milliseconds
org.omg.CORBA.COMM_FAILURE: WARNING: IOP00410019: Communications timeout waiting for response. Exceeded 1,800,000 milliseconds vmcid: OMG minor code: 19 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 $Proxy25.communicationsTimeoutWaitingForResponse(Unknown Source)
at com.sun.corba.ee.impl.transport.CorbaResponseWaitingRoomImpl.waitForResponse(CorbaResponseWaitingRoomImpl.java:183)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.waitForResponse(SocketOrChannelConnectionImpl.java:1021)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.waitForResponse(CorbaMessageMediatorImpl.java:279)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:407)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:368)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:273)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
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.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at LookupTest.lookupBothBeans(LookupTest.java:32)
at LookupTest.testSleep(LookupTest.java:64)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Tue Feb 22 21:33:30 CET 2011 - Response from server: Hello from Session Bean 2, took: 1955251ms.
Starting round 5
Tue Feb 22 21:34:00 CET 2011 - Response from server: Hello from Session Bean 2, took: 930ms.
Starting round 6
Tue Feb 22 21:34:31 CET 2011 - Response from server: Hello from Session Bean 2, took: 901ms.
Starting round 7
Tue Feb 22 21:35:02 CET 2011 - Response from server: Hello from Session Bean 2, took: 901ms.
Starting round 8
Tue Feb 22 21:35:33 CET 2011 - Response from server: Hello from Session Bean 2, took: 871ms.

We tried to reduce the timeout time with the property "com.sun.corba.ee.transport.ORBWaitForResponseTimeout", but this call should not time out in the first place.

Thank you for a prompt investigation,

• Andreas

Environment

Client runs on Mac OS X 10.6.6 or Ubuntu 10

Affected Versions

[current]

In our application we observe that ORBImpl#destroy does not close the IIOP server socket.

To me it looks like in SelectorImpl there should be a listener thread to close the socket. However, the SelectorImpl#registerForEvent calls end up in the deferredRegistrations case, where no listener thread is created. The deferredRegistrations case is determined by the useSelectThreadToWait flag, which must definitely be true, because otherwise the ORB blocks completely. S. #26 for details.

• Uptake new Eclipse versions of dependencies. Use GlassFish 5.1 Release Tracker wiki to find components versions to use.

• Release to OSSRH staging repository

• Update GlassFish 5.1 Release Tracker with released version number.

How to release first versions of EE4J components

Sporadic error when transferring large byte arrays (e.g. 10 MB)

Bug is "com.sun.corba.ee.impl.encoding.BufferManagerReadStream.java"

The "underflow" method the "fragmentQueue.wait(orb.getORBData().fragmentReadTimeout())" returns unexplainable,
but it is NOT the due to the timeout, since it returnes after some milliseconds.
It looks like it get's notified without having the "fragmentQueue" properly enqueued, which I cannot explain.
So there is this "IOP00410037: Timeout while reading data in buffer manager",
but it is definitely no time out, also because it is thrown after some milliseconds, and this time out actually is 18 seconds.

This can be easily reproduced with the following very simple test.
It takes about a couple hundred tries (might take some minutes) until I get this error.
Even when client and server run on the same machine.

package de.test.client;

import javax.naming.Context;
import javax.naming.InitialContext;
import de.test.service.remote.TimeoutTestService;

public class TimeoutTestClient {
private static int tryNumber = 0;
private static boolean running = true;

public static void main(String[] args) throws Exception {
Context initialContext = new InitialContext();
TimeoutTestService timeoutTestService = (TimeoutTestService) initialContext.lookup(TimeoutTestService.class.getName());

long startTime = 0;
while (running) {
try

{ tryNumber++; startTime = System.currentTimeMillis(); timeoutTestService.getBytes(10000000); }

catch (Exception e)

{ System.out.println("Error occured at try number: " + tryNumber + " after " + (System.currentTimeMillis() - startTime) + " millis"); e.printStackTrace(); running = false; }

}
}
}

package de.test.service.remote;

import javax.ejb.Remote;

@Remote
public interface TimeoutTestService {
byte[] getBytes(int size);
}

package de.test;

import javax.ejb.Stateless;
import de.test.service.remote.TimeoutTestService;

@stateless
public class TimeoutTestServiceBean implements TimeoutTestService {
public byte[] getBytes(int size) {
byte[] bytes = new byte[size];
for (int i = 0; i < bytes.length; i++)

{ bytes[i] = 0x42; }

return bytes;
}
}

Environment

Windows 7, Glassfish 3.1, jdk1.6.0_26

Affected Versions

[current]

Last CTS runs indicate no failures in this component. It's time to make a public release. Before the release make sure that Eclipse Release Review is passed and all dependencies have been released.

This is a place holder issue for Pull request from javaee/glassfish-corba#25

When an input stream is marked, the underlying byteBuffer is duplicated using the java.nio.ByteBuffer.duplicate() function which does not replicate the buffer byte order.

This breaks the processing of little endian user exception replies which peeks at the exception id and resets the input stream with the wrong byte order.

• Integrate to Eclipse GlassFish
• Pass all CTS/TCK tests

All other Corba components are integrated as part of Orb integration.

org.glassfish.corba.annotation.processing.ExceptionWrapperProcessor is annotated with @SupportedSourceVersion(SourceVersion.RELEASE_6).

This annotation sets the "the latest source version an annotation processor supports."

As a consequence, there are lots of warnings when the jar is on the compile classpath, because the annotation processor is enabled by default via META-INF/services/javax.annotation.processing.Processor

For example with Java 11:

[WARNING] Supported source version 'RELEASE_6' from annotation processor 'org.glassfish.corba.annotation.processing.ExceptionWrapperProcessor' less than -source '11'