eclipse-ee4j / orb Goto Github PK
View Code? Open in Web Editor NEWEclipse ORB is a CORBA orb for use in Jakarta EE and GlassFish and other projects that still need an ORB.
Home Page: https://projects.eclipse.org/projects/ee4j.orb
License: Other
Eclipse ORB is a CORBA orb for use in Jakarta EE and GlassFish and other projects that still need an ORB.
Home Page: https://projects.eclipse.org/projects/ee4j.orb
License: Other
This is a place holder issue for Pull request from javaee/glassfish-corba#25
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]
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;
....
w7-vs2010-64
IDL-to-Java compiler (portable), version "3.2"
This is a place holder issue for Pull request from javaee/glassfish-corba#24
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.
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.
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")) {
...
}
...
}
Running GF Quicklook with JDK7U25 or later causes a test failure:
[testng] ===============================================
[testng] ejb_remoteview
[testng] Tests run: 3, Failures: 1, Skips: 2
[testng] ===============================================
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.
solaris, linux, mac, windows
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 ;
}
// [...]
}
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.
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
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.
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.)
any
[current]
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.
Glassfish 3.1.2.2
[current]
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.
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'
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/.
This is a place holder issue for Pull request from javaee/glassfish-corba#21
Can this code be fixed RepositoryId.java#L1000?
Method convertFromISOLatin1 doesn't correctly decodes id encoded by convertToISOLatin1 in case of multibyte values.
All other Corba components are integrated as part of Orb integration.
GlassFish 4.1 has a severe performance regression from GlassFish 4.0.
See Payara issue for detailed analysis and a fix
GlassFish 4.1
This involves verifying following scenarios:
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
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;
}
}
Windows 7, Glassfish 3.1, jdk1.6.0_26
[current]
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)
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.
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
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.
Operating System: All
Platform: All
[current]
as is required and documented in https://www.eclipse.org/projects/handbook/#legaldoc
It should now be "oss-release"
Add code coverage & reporting to Maven
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.
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.
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.
I want to use the com.sun.jndi.cosnaming.CNCtxFactory
on JDK 11+.
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.
Operating System: All
Platform: All
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:
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,
Client runs on Mac OS X 10.6.6 or Ubuntu 10
[current]
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.
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 ...
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.
Additional information:
This is a place holder issue for Pull request from javaee/glassfish-corba#23
Convert build to Maven
This issue was unavailable for migration from original issue tracker.
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.
[current]
This task is for creating a project release CI/CD pipeline.
Use these documents as a reference:
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.
This is a place holder issue for Pull request from javaee/glassfish-corba#22
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) {
The above-mentioned bug-fix is included in latest glassfish.
https://hg.java.net/hg/glassfish-corba~hg/rev/7014b5cd2039
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.
The pfl-test component is not needed by the orb production code, but it is included in its dependency list.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.