Re: [glassfish-dev] What are the possible causes of remote JNDI lookup f

[Scott Marlow <smarlow@xxxxxxxxxx>]

On 10/25/24 3:12 PM, Scott Marlow wrote:

On 10/23/24 9:12 AM, Steve Millidge (Payara) wrote:

Not sure if a cnfe could cause that while traversing the JNDI reference.

There is something slightly different in the JNDI names 

#com.sun.ts.tests.common.vehicle.stateless3.Stateless3VehicleIF

Between Failed lookup above and the deployment name below

com_sun_ts_tests_common_vehicle_Stateless3VehicleBean#com.sun.ts.tests.common.vehicle.stateless3.Stateless3VehicleIF

It's missing the bean prefix. I'm not sure if this is normal from memory. At this point I would be debugging the JNDI code on the server to list the jndi references  :-(

I can debug the server side now, which class is best to set a breakpoint in for debugging the JNDI code on the server to list the jndi references? 

After deployment completes and lots of jndi lookups to deal with derby, I see the following jndi calls:

1. jndi list "" returns:

"com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__" -> {javax.naming.Reference@13703} "Reference Class Name: reference\nType: url\nContent: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__\n"
"com_sun_ts_tests_common_vehicle_AppManagedVehicleBean#com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF" -> {javax.naming.Reference@13653} "Reference Class Name: com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF\nType: url\nContent: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__\n"
"com_sun_ts_tests_common_vehicle_AppManagedVehicleBean" -> {javax.naming.Reference@13696} "Reference Class Name: com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF\nType: url\nContent: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__\n"

2. jndi lookup of com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__
   finds Reference Class Name: reference
Type: url
Content: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__
and returns IORImpl[type=RMI:com.sun.ejb.codegen.GenericEJBHome_Generated:0000000000000000 iorTemplates=[IORTemplate[oktemp=ObjectKeyTemplate[magic=afabcb00 scid=38 serverid=100 orbid=S1AS-ORB oaid=ObjectAdapterID[RootPOA/#RFMBase#/113482914926166016_RBusiness_com.sun.ts.tests.common.vehicle.appmanaged._AppManagedVehicleIF_Remote-EJBHome] profile templates:[IIOPProfileTemplateImpl[giopVersion=1.2 primary=192.168.122.1:3700]]]]

3.  jndi look up name com_sun_ts_tests_common_vehicle_AppManagedVehicleBean finds Reference Class Name: com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF
Type: url
Content: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__
and returns Reference Class Name: com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF
Type: url
Content: com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__

4. jndi look up of com_sun_ts_tests_common_vehicle_AppManagedVehicleBean__3_x_Internal_RemoteBusinessHome__ returns IORImpl[type=RMI:com.sun.ejb.codegen.GenericEJBHome_Generated:0000000000000000 iorTemplates=[IORTemplate[oktemp=ObjectKeyTemplate[magic=afabcb00 scid=38 serverid=100 orbid=S1AS-ORB oaid=ObjectAdapterID[RootPOA/#RFMBase#/113482914926166016_RBusiness_com.sun.ts.tests.common.vehicle.appmanaged._AppManagedVehicleIF_Remote-EJBHome] profile templates:[IIOPProfileTemplateImpl[giopVersion=1.2 primary=192.168.122.1:3700]]]]

So it seems like the appclient process is not seeing the session bean returned but the server side does create the (looked up) session bean I think.

Scott

I did reach (by luck):

intercept:310, InterceptorManager (com.sun.ejb.containers.interceptors)
1 hidden frame
aroundConstruct:60, CDIAroundConstructCallback (org.glassfish.weld.services)
7 hidden frames
_createCDIInjectionContext:249, CDIServiceImpl (org.glassfish.weld.services)
createCDIInjectionContext:179, CDIServiceImpl (org.glassfish.weld.services)
23 hidden frames

for ##########################################################
InterceptorManager<com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleBean> has 1 interceptors
beanClassName: com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleBean
Interceptors:
org.jboss.weld.module.ejb.SessionBeanInterceptor
Callback Interceptors:
0: interface jakarta.interceptor.AroundConstruct
CallbackInterceptorChainImpl
1: interface jakarta.annotation.PostConstruct
CallbackInterceptorChainImpl
callback[0]: public java.lang.Object org.jboss.weld.module.ejb.SessionBeanInterceptor.aroundInvoke(jakarta.interceptor.InvocationContext) throws java.lang.Exception
2: interface jakarta.annotation.PreDestroy
CallbackInterceptorChainImpl
3: interface jakarta.ejb.PrePassivate
CallbackInterceptorChainImpl
4: interface jakarta.ejb.PostActivate
CallbackInterceptorChainImpl

But soon after GlassFish Server seemed to be out of sync with the Application Client as per:

Next is failure:
this = {com.sun.corba.ee.impl.transport.ConnectionImpl@16843} "SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/192.168.0.35:3700 remote=/192.168.0.35:39580] ESTABLISHED true true]"
this = {com.sun.corba.ee.impl.transport.ConnectionImpl@16843} "SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/192.168.0.35:3700 remote=/192.168.0.35:39580] ESTABLISHED true true]"
Exception = {java.io.IOException@16841}
 backtrace = {java.lang.Object[6]@16848}
 detailMessage = "End-of-stream"
 cause = {java.io.IOException@16841} "java.io.IOException: End-of-stream"
 stackTrace = {java.lang.StackTraceElement[5]@16851}
 depth = 5
 suppressedExceptions = {java.util.Collections$EmptyList@16684}  size = 0
3:01
FINE: 00410011: IOException received when reading from connection SocketOrChannelConnectionImpl[ java.nio.channels.SocketChannel[connected local=/192.168.0.35:3700 remote=/192.168.0.35:39580] ESTABLISHED true true]

Scott