I want to start a RabbitMQ source and then sink, but I not able to perform first step i.e starting Rabbit MQ source . RabbitMQ server is running and I can see dashboard as well.
My code is as below
public class rabbitmq_source {
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment envrionment = StreamExecutionEnvironment.getExecutionEnvironment();
RMQConnectionConfig connectionConfig = new RMQConnectionConfig.Builder()
.setHost("localhost")
.setPort(50000).
setUserName("root")
.setPassword("root").
setVirtualHost("/").build();
DataStream<String> stream = envrionment
.addSource(new RMQSource<String>(
connectionConfig, // config for the RabbitMQ connection
"queue", // name of the RabbitMQ queue to consume
new SimpleStringSchema()));
stream.print();
envrionment.execute();
}
}
I am not sure what username and pass should I set, should they be guest and guest. However, I am getting the following error
java.lang.RuntimeException: Cannot create RMQ connection with queue at localhost
at org.apache.flink.streaming.connectors.rabbitmq.RMQSource.open(RMQSource.java:172)
at org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:111)
at org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:376)
at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:253)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:702)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at com.rabbitmq.client.impl.FrameHandlerFactory.create(FrameHandlerFactory.java:32)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:588)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:612)
Use LocalStreamEnvironment.createLocalEnvironment() with guest username and password.
Related
I have setup a standalone Redis server (v 7.0.4). I have configured a password for it using requirepass config. I am using Jedis (v 4.2.0) as the client.
Following is the code for creating JedisPool to connect with Redis -
public JedisConnectionPool(final JedisPoolConfig poolConfig, final String host, int port, int timeout, final String password) {
this.pool = new JedisPool(poolConfig, host, port, timeout, password);
}
I have a sequence of updates coming together, some updates are completed successfully, then I start getting following error -
Caused by: redis.clients.jedis.exceptions.JedisDataException: NOAUTH Authentication required.
at redis.clients.jedis.Protocol.processError(Protocol.java:96) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Protocol.process(Protocol.java:137) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Protocol.read(Protocol.java:192) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Connection.getOne(Connection.java:298) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Connection.executeCommand(Connection.java:123) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Jedis.get(Jedis.java:4901) ~[jedis-4.2.0.jar:na]
This error occurs multiple times, then following error comes -
2022-11-23 04:04:39.124 ERROR 62960 --- [ns-pool-evictor] redis.clients.jedis.JedisFactory : Error while validating pooled Jedis object.
redis.clients.jedis.exceptions.JedisDataException: NOAUTH Authentication required.
at redis.clients.jedis.Protocol.processError(Protocol.java:96) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Protocol.process(Protocol.java:137) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Protocol.read(Protocol.java:192) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:243) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.Jedis.ping(Jedis.java:356) ~[jedis-4.2.0.jar:na]
at redis.clients.jedis.JedisFactory.validateObject(JedisFactory.java:211) ~[jedis-4.2.0.jar:na]
at org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:745) ~[commons-pool2-2.11.1.jar:2.11.1]
at org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:160) ~[commons-pool2-2.11.1.jar:2.11.1]
at org.apache.commons.pool2.impl.EvictionTimer$WeakRunner.run(EvictionTimer.java:113) ~[commons-pool2-2.11.1.jar:2.11.1]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[na:na]
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[na:na]
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[na:na]
at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na]
After this the remaining updates are updates successfully to Redis.
As the same JedisPool is used to get Jedis Connection objects, I don't understand why there is NOAUTH error for some updates while others are completed successfully.
Can someone help resolve this?
One of the possibilities is that the underlying socket of the Jedis object was actually closed and so its AUTHed state is cleared. This may happen if the Jedis object borrowed from JedisPool is closed twice (or multiple times). Because first close() would return the object to the pool but subsequent close() would cause the underlying socket object to be closed.
Check of the Jedis object borrowed from JedisPool is closed multiple times. If you use try-with-resources, one close operation could be hidden, e.g.
try (Jedis jedis = this.pool.getResource()) {
// operations by jedis
jedis.close(); // <-- first, visible close
} // <-- second, hidden close
I have a Spring Boot application interfacing with a rabbitmq broker which manages to startup fine but I am getting a constant start/shutdown of the message consumer regardless of there being a message on the queue. Below is a copy of my application log and client class:
2016-10-19 11:40:25,909 WARN t:[SimpleAsyncTaskExecutor-106] SimpleMessageListenerContainer: Consumer raised exception, processing can restart if the connection factory supports it
java.lang.NullPointerException: null
at com.rabbitmq.client.impl.ChannelN.validateQueueNameLength(ChannelN.java:1232) ~[amqp-client-3.5.5.jar:na]
at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:884) ~[amqp-client-3.5.5.jar:na]
at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:61) ~[amqp-client-3.5.5.jar:na]
at sun.reflect.GeneratedMethodAccessor334.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_51]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_51]
at org.springframework.amqp.rabbit.connection.CachingConnectionFactory$CachedChannelInvocationHandler.invoke(CachingConnectionFactory.java:666) ~[spring-rabbit-1.4.6.RELEASE.jar:na]
at com.sun.proxy.$Proxy181.queueDeclarePassive(Unknown Source) ~[na:na]
at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.attemptPassiveDeclarations(BlockingQueueConsumer.java:533) ~[spring-rabbit-1.4.6.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:453) ~[spring-rabbit-1.4.6.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1083) ~[spring-rabbit-1.4.6.RELEASE.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
2016-10-19 11:40:25,909 INFO t:[SimpleAsyncTaskExecutor-106] SimpleMessageListenerContainer: Restarting Consumer: tags=[{}], channel=Cached Rabbit Channel: AMQChannel(amqp://guest#127.0.0.1:5672/,1), acknowledgeMode=AUTO local queue size=0
2016-10-19 11:40:25,910 DEBUG t:[SimpleAsyncTaskExecutor-106] BlockingQueueConsumer: Closing Rabbit Channel: Cached Rabbit Channel: AMQChannel(amqp://guest#127.0.0.1:5672/,1)
2016-10-19 11:40:25,910 DEBUG t:[SimpleAsyncTaskExecutor-106] CachingConnectionFactory: Closing cached Channel: AMQChannel(amqp://guest#127.0.0.1:5672/,1)
2016-10-19 11:40:25,911 DEBUG t:[SimpleAsyncTaskExecutor-107] DefaultListableBeanFactory: Returning cached instance of singleton bean 'macRequestQueue'
2016-10-19 11:40:25,911 DEBUG t:[SimpleAsyncTaskExecutor-107] BlockingQueueConsumer: Starting consumer Consumer: tags=[{}], channel=null, acknowledgeMode=AUTO local queue size=0
2016-10-19 11:40:25,912 DEBUG t:[SimpleAsyncTaskExecutor-107] CachingConnectionFactory: Creating cached Rabbit Channel from AMQChannel(amqp://guest#127.0.0.1:5672/,1)
2016-10-19 11:40:25,912 DEBUG t:[SimpleAsyncTaskExecutor-107] SimpleMessageListenerContainer: Recovering consumer in 5000 ms.
Below is a copy of my client class:
public class RabbitClientConfiguration extends AbstractEMCRabbitConfiguration {
#Inject
private JacksonConfiguration jacksonConfiguration;
#Inject
private MessagingConfiguration messagingConfiguration;
//#Value("${data.core.pattern}")
//private String coreDataRoutingKey;
//#Inject
//private ClientHandler clientHandler;
#Override
public void configureRabbitTemplate(RabbitTemplate rabbitTemplate) {
rabbitTemplate.setRoutingKey(MAC_REQUEST_ROUTING_KEY);
}
#Bean
public SimpleMessageListenerContainer messageListenerContainer(){
SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();
container.setConnectionFactory(connectionFactory());
container.setQueueNames(MAC_REQUEST_QUEUE_NAME);
container.setMessageListener(messageListenerAdapter());
container.setAcknowledgeMode(AcknowledgeMode.AUTO);
return container;
}
#Bean
MessageListenerAdapter messageListenerAdapter(){
return new MessageListenerAdapter(clientHandler(jacksonConfiguration.objectMapper(),messagingConfiguration.macMessageHandler(messagingConfiguration.messagingFactory())),jsonMessageConverter());
//return new MessageListenerAdapter(clientHandler,"receiveMessage");
}
#Bean
ClientHandler clientHandler(ObjectMapper objectMapper, IMessageHandler macMessageHandler){
ClientHandler clientHandler = new ClientHandler();
clientHandler.setObjectMapper(objectMapper);
clientHandler.setMacMessageHandler(macMessageHandler);
return clientHandler;
}
#Bean
public AmqpAdmin rabbitAdmin() { return new RabbitAdmin(connectionFactory());}
}
java.lang.NullPointerException: null at com.rabbitmq.client.impl.ChannelN.validateQueueNameLength
It means MAC_REQUEST_QUEUE_NAME contains null - it looks like the container doesn't check that when you call the setter.
I opened a JIRA Issue to detect this condition.
WinSCP based same connection using account name, passphrase and private key for connection. But trying from code am getting this exception continuously.
Code:
try
{
session.connect();
System.out.println("session is alive:" + session.isConnected());
channel = session.openChannel("sftp");
channel.connect();
channelSftp = (ChannelSftp) channel;
channelSftp.connect();
channelSftp.chmod(777, depDir);
}
catch (Exception e1)
{
e1.printStackTrace();
System.out.println("Manual Exception in updateDepositedFilePermission:" + CommonUtil.getExceptionString(e1));
}
Output:
session is alive:true
Manual Exception in updateDepositedFilePermission:com.jcraft.jsch.JSchException: failed to send sftp request
at com.jcraft.jsch.RequestSftp.request(Unknown Source)
at com.jcraft.jsch.ChannelSftp.start(Unknown Source)
at com.jcraft.jsch.Channel.connect(Unknown Source)
at com.app.sftp.CheckFTP.main(CheckFTP.java:730)
session is alive:true
com.jcraft.jsch.JSchException: failed to send sftp request
at com.jcraft.jsch.RequestSftp.request(Unknown Source)
at com.jcraft.jsch.ChannelSftp.start(Unknown Source)
at com.jcraft.jsch.Channel.connect(Unknown Source)
at com.app.sftp.CheckFTP.main(CheckFTP.java:730)
Not sure it's the main problem, but you are calling Channel.connect() twice.
First here:
channel.connect();
And again here:
channelSftp.connect();
Remove the second call.
We are using a servlet to access a remote ejb deployed on a different host and getting the
exception mentioned in the stacktrace below.
The remote access works if the servlet client and the remote ejb war are deployed in different domains and on the same host.
Works if they are deployed on the same host and same domain
does not work when deployed on two diffrent hosts.
Looking at the exception"CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 0 completed: No", we thought it could be security issue.
But the test ejb application didnt have any security configurations. Tried adding the "" details to the sun-ejb-jar.xml
and used ProgrammaticLogin api. We got the same exception. Not sure if the security config was correct though.
The glassfish-corba log level was set to finest in the server where the ejb application was deployed. We then got this exception, "
org.omg.CORBA.BAD_INV_ORDER: FINE: IOP01600015: Service context add failed in portable interceptor because a service context with id 15 already exists vmcid: SUN minor code: 15 completed: No".
The full stacktrace is mentioned below in the server log.
tried using the front-end back-end test cases from Glassfish bug: http://java.net/jira/browse/GLASSFISH-15523. We are
getting the same exception.
Glassfish version: 3.1 build 43
Not sure where we are going wrong. Please help. Thanks.
Client Side log:
Caused by: javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=TestService,Remote 3.x interface =com.medallion.test.service.TestService,ejb-link=null,lookup=,mappedName=,jndi-name=corbaname:iiop:50.57.150.62:3700#TestService,refType=Session' . Actual (possibly internal) Remote JNDI name used for lookup is 'corbaname:iiop:50.57.150.62:3700#TestService__3_x_Internal_RemoteBusinessHome__' [Root exception is org.omg.CORBA.BAD_PARAM: FINE: IOP00100009: string_to_object conversion failed due to bad schema specific part in name TestService__3_x_Internal_RemoteBusinessHome__ vmcid: SUN minor code: 9 completed: No]
at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:178)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:1106)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:776)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:744)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:172)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
... 38 more
Caused by: org.omg.CORBA.BAD_PARAM: FINE: IOP00100009: string_to_object conversion failed due to bad schema specific part in name TestService__3_x_Internal_RemoteBusinessHome__ vmcid: SUN minor code: 9 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy142.soBadSchemaSpecific(Unknown Source)
at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.resolveCorbaname(INSURLOperationImpl.java:227)
at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.resolveINSURL(INSURLOperationImpl.java:154)
at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.operate(INSURLOperationImpl.java:145)
at com.sun.corba.ee.impl.orb.ORBImpl.string_to_object(ORBImpl.java:976)
at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:171)
... 43 more
Caused by: org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 0 completed: No
at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.handle_null_service_context(SecServerRequestInterceptor.java:421)
at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:443)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:612)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:612)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:333)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:196)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
----------END server-side stack trace---------- vmcid: 0x0 minor code: 0 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:900)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:131)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:637)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:499)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:373)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:273)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:395)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
at org.omg.CosNaming.NamingContextExtHelper.narrow(NamingContextExtHelper.java:73)
at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.resolveCorbaname(INSURLOperationImpl.java:212)
... 47 more
Server Side log( after setting the corba log level to finest):
[#|2011-12-02T11:37:16.111-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=161;_ThreadName=Thread-2;ClassName=org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory;MethodName=setAcceptedSocketOptions;|setAcceptedSocketOptions: SocketOrChannelAcceptorImpl[3700 IIOP_CLEAR_TEXT true true] ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=3700] Socket[addr=/173.13.42.205,port=54829,localport=3700]|#]
[#|2011-12-02T11:37:16.113-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba|_ThreadID=15;_ThreadName=Thread-2;ClassName=com.sun.logging.LogDomains$1;MethodName=getResourceBundle;|Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager|#]
[#|2011-12-02T11:37:16.180-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba|_ThreadID=161;_ThreadName=Thread-2;ClassName=com.sun.logging.LogDomains$1;MethodName=getResourceBundle;|Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager|#]
[#|2011-12-02T11:37:16.179-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=161;_ThreadName=Thread-2;ClassName=org.glassfish.enterprise.iiop.impl.POAProtocolMgr;MethodName=getEjbDescriptor;|POAProtocolMgr.getEjbDescriptor->: [B#77dc7838|#]
[#|2011-12-02T11:37:16.181-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba|_ThreadID=161;_ThreadName=Thread-2;ClassName=com.sun.logging.LogDomains$1;MethodName=getResourceBundle;|Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager|#]
[#|2011-12-02T11:37:16.181-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=161;_ThreadName=Thread-2;ClassName=org.glassfish.enterprise.iiop.impl.POAProtocolMgr;MethodName=getEjbDescriptor;|POAProtocolMgr.getEjbDescriptor: [B#77dc7838: ejbId: 4,294,967,297|#]
[#|2011-12-02T11:37:16.181-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba|_ThreadID=161;_ThreadName=Thread-2;ClassName=com.sun.logging.LogDomains$1;MethodName=getResourceBundle;|Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager|#]
[#|2011-12-02T11:37:16.181-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=161;_ThreadName=Thread-2;ClassName=org.glassfish.enterprise.iiop.impl.POAProtocolMgr;MethodName=getEjbDescriptor;|POAProtocolMgr.getEjbDescriptor<-: [B#77dc7838: null|#]
[#|2011-12-02T11:37:16.183-0600|FINE|glassfish3.1.1|javax.enterprise.resource.corba.OMG|_ThreadID=161;_ThreadName=Thread-2;ClassName=com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator;MethodName=handleFullLogging;|IOP01600015: Service context add failed in portable interceptor because a service context with id 15 already exists
org.omg.CORBA.BAD_INV_ORDER: FINE: IOP01600015: Service context add failed in portable interceptor because a service context with id 15 already exists vmcid: SUN minor code: 15 completed: No
at sun.reflect.GeneratedConstructorAccessor729.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy210.serviceContextAddFailed(Unknown Source)
at com.sun.corba.ee.impl.interceptors.ServerRequestInfoImpl.enqueue(ServerRequestInfoImpl.java:702)
at com.sun.corba.ee.impl.interceptors.ServerRequestInfoImpl.add_reply_service_context(ServerRequestInfoImpl.java:482)
at com.sun.corba.ee.impl.interceptors.ServerRequestInfoImpl.setCurrentExecutionPoint(ServerRequestInfoImpl.java:738)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIEndingPoint(PIHandlerImpl.java:632)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.runInterceptors(CorbaMessageMediatorImpl.java:2189)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2101)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2089)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2014)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1796)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1758)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:255)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
|#]
Code used:
Client:
servlet:
#WebServlet("/TestServlet")
public class TestServlet extends HttpServlet {
#EJB(name = "TestService")
private TestService testService;
/**
* #see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
*/
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter w = response.getWriter();
try {
w.write("Test o/p: " + testService.testEJB("This is a test msg") + "\n");
} catch (Exception e) {
e.printStackTrace(w);
}
}
}
sun-web.xml:
<ejb-ref>
<ejb-ref-name>TestService</ejb-ref-name>
<!-- <jndi-name>corbaname:iiop:localhost:3700#TestService</jndi-name> -->
<jndi-name>corbaname:iiop:<ip>:3700#TestService</jndi-name>
</ejb-ref>
Remote ejb:
#Stateless(mappedName="TestService")
public class TestServiceImpl implements Serializable, TestService {
private static final long serialVersionUID = 1L;
private static final Logger logger = Logger.getLogger(TestServiceImpl.class.getName());
#Resource EJBContext ejbContext;
#Override
public String testEJB(String testStr) {
String userName = ejbContext.getCallerPrincipal().getName();
System.out.println("Username: " + userName);
return "Msg Recieved: " + testStr;
}
sun-ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>TestServiceImpl</ejb-name>
<jndi-name>TestService</jndi-name>
<!--<ior-security-config>
<as-context>
<auth-method>USERNAME_PASSWORD</auth-method>
<realm>database-realm</realm>
<required>true</required>
</as-context>
<sas-context>
<caller-propagation>supported</caller-propagation>
</sas-context>
<transport-config>
<establish-trust-in-client>supported</establish-trust-in-client>
</transport-config>
</ior-security-config>-->
</ejb>
</enterprise-beans>
<security-role-mapping>
</security-role-mapping>
</sun-ejb-jar>
Perhaps not the answer to your question but I'll mention this here:
We had a similar problem with glassfish 3.1.2 where the occurring exception mentions CORBA.NO_PERMISSION and there is no stacktrace on the server side. Somewhere in the logfile we found the Exception Invalid iiop-listener orb-listener-1. Lazy-init not supported for SSL iiop-listeners
This is a bug in glassfish see:
https://java.net/jira/browse/GLASSFISH_CORBA-13
The glassfish admin interface automatically adds an SSL entry to the configured non SSL iiop-listener, due to this, the exception occures and remoting won't work anymore. As workaround you can remove the SSL-config-entry from the domain.xml manually to get remoting work again. But a soon as you open the IOP-Listener section again in the admin interface, the entry will be created again on glassfish restart.
I am using JCR 1.0 and I am having problems re-opening JCR connections after I close them.
Here are my two helper methods:
private void openConnection() throws Exception {
loadDbProperties();
repository = new TransientRepository(repositoryConfig,repositoryHome);
session = repository.login(new SimpleCredentials("testUserName","testPassword".toCharArray()));
ws = session.getWorkspace();
rootNode = session.getRootNode();
}
private void closeConnection() throws Exception {
session.save();
session.logout();
session = null;
repository = null;
}
I have two methods called, addProperty() and getProperty(), both need a connection to the JCR repository. I placed the openConnection() and closeConnection() methods at the beginning of both add and get methods but it seems that whichever method runs second is not able to re-open an already closed connection.
This is the exception I get:
javax.faces.el.EvaluationException: javax.jcr.RepositoryException: this session has been closed
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:775)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1267)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:550)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:380)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:288)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.jcr.RepositoryException: this session has been closed
at org.apache.jackrabbit.core.SessionImpl.sanityCheck(SessionImpl.java:340)
at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:154)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1751)
at pgts.trueMiner.core.dao.TenureDAOImpl.addTenure(TenureDAOImpl.java:63)
at pgts.trueMiner.core.biz.TenureServiceImpl.addTenure(TenureServiceImpl.java:63)
at pgts.trueMiner.core.ui.TenureForm.addTenure(TenureForm.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:98)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
... 23 more
How do you re-open the same connection? I don't want to always keep the connection open because a lock will prevent other applications from using the repository.
It looks like you try to add a node after the session was closed. I can reproduce the exception using the following test case:
Repository repository = new TransientRepository();
Session session = repository.login(
new SimpleCredentials("admin", "admin".toCharArray()));
session.getWorkspace();
Node rootNode = session.getRootNode();
session.save();
session.logout();
rootNode.addNode("test");
With a recent version of Jackrabbit (I used Jackrabbit trunk) you will get the stack trace of where the session was closed:
Exception in thread "main" javax.jcr.RepositoryException: This session has been closed. See the chained exception for a trace of where the session was closed.
at org.apache.jackrabbit.core.session.SessionState.checkAlive(SessionState.java:121)
at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:171)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.NodeImpl.addNodeWithUuid(NodeImpl.java:1790)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1742)
at org.apache.jackrabbit.api.Test.main(Test.java:21)
Caused by: java.lang.Exception: Stack trace of where session-admin-4 was originally closed
at org.apache.jackrabbit.core.session.SessionState.close(SessionState.java:246)
at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:888)
at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:389)
at org.apache.jackrabbit.api.Test.main(Test.java:20)