Handling org.elasticsearch.client.transport.NoNodeAvailableException - spring-boot

Hi In my SpringBoot project i have configured elastic search using JPA. I am using ElasticsearchRepository for it. Now for the configuration when i am using localhost then everything works fine but when i am putting IP address then i am facing an exception-
org.elasticsearch.client.transport.NoNodeAvailableException: None of
the configured nodes are available:
[{#transport#-1}{lDnuVli1Rriy-9j1pdozZA}{27.101.12.99}{27.101.12.99:9300}]
at
org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:347)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:245)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:408)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:80)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:54)
~[elasticsearch-5.6.11.jar:5.6.11] at
org.springframework.data.elasticsearch.core.ElasticsearchTemplate.index(ElasticsearchTemplate.java:571)
~[spring-data-elasticsearch-3.0.10.RELEASE.jar:3.0.10.RELEASE] at
org.springframework.data.elasticsearch.repository.support.AbstractElasticsearchRepository.save(AbstractElasticsearchRepository.java:156)
~[spring-data-elasticsearch-3.0.10.RELEASE.jar:3.0.10.RELEASE] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_151] at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
~[na:1.8.0_151] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
~[na:1.8.0_151] at java.lang.reflect.Method.invoke(Unknown Source)
~[na:1.8.0_151]
Code for initlizing Elastic Search -
#Bean
public Client client() throws Exception {
Settings settings = Settings.builder()
.put("cluster.name",getElasticCluster())
.build();
return new PreBuiltTransportClient(Settings.EMPTY)
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(getElasticHost()),getElasticPort()));
}
#Bean
public ElasticsearchOperations elasticsearchTemplate() throws Exception {
return new ElasticsearchTemplate(client());
}
elasticsearch:
jest:
proxy:
host: 27.101.12.99
port: 9300
I had a lot of search but nothing is helpful in my case. So Please check and help.

The elasticsearch client in your application is joning the cluster using the transport protocoll. This approach is deprecated and already removed in recent releases.
This said transport protocoll is not HTTP and your jest proxy probably fails to analyse/mock the data send. This is the reason why localhost works but jest proxy fails.
In order to have your application compatible with future releases of elasticsearch you should consider using the high level REST client without loosing any functionality for the spring app. And as a quick win you´ll be able to use jest again because the REST client is using HTTP to communicate with elasticsearch.
Please have a look on this for details about the client migration (I assumed the elasticsearch version based on the stacktrace, please double ckeck it) https://www.elastic.co/guide/en/elasticsearch/client/java-rest/5.6/java-rest-high-level-migration.html

Related

How do i stop hibernate search from sniffing the nodes of a non-existent local elastic search server?

I've created a open search service domain on AWS and i've set the property hibernate.search.backend.uris to the address of that domain. Everything works fine, i'm able to index my entity tables and can run search queries against the open search service domain.
Yet for some reason hibernate search still routinely tries to connect to localhost:9200 in order to perform a node sniffing routine. This obviously doesn't work and the exception [es_rest_client_sniffer[T#1]] Sniffer - error while sniffing nodes java.net.ConnectException: Connection refused: no further information is thown.
How do i stop hibernate search from performing this futile action? It keeps trying to sniff the nodes every few minutes or so. I've tried setting the fields hibernate.search.backend.hosts and hibernate.search.backend.protocol instead of .uris. But even when i set those properties instead hibernate search still tries to interact with a non-existent elastic search service on localhost. I am running hibernate search 6.1.5.Final. The elastic search version is set to 7.16.3. Here are all the relevant properties that i set programmatically.
jpaProperties.put("hibernate.search.backend.aws.credentials.type", "static");
jpaProperties.put("hibernate.search.backend.aws.credentials.access_key_id", awsId);
jpaProperties.put("hibernate.search.backend.aws.credentials.secret_access_key", awsKey);
jpaProperties.put("hibernate.search.backend.aws.region", openSearchAwsInstanceRegion);
jpaProperties.put("hibernate.search.backend.aws.signing.enabled", true);
//--------------------------------------------------------------------------------------------
jpaProperties.put("hibernate.search.automatic_indexing.synchronization.strategy", indexSynchronizationStrategy);
jpaProperties.put("hibernate.search.backend.request_timeout", requestTimeout);
jpaProperties.put("hibernate.search.backend.connection_timeout", elasticSearchConnectionTimeout);
jpaProperties.put("hibernate.search.backend.read_timeout", readTimeout);
jpaProperties.put("hibernate.search.backend.max_connections", maximumElasticSearchConnections);
jpaProperties.put("hibernate.search.backend.max_connections_per_route", maximumElasticSearchConnectionsPerRout);
jpaProperties.put("hibernate.search.schema_management.strategy", schemaManagementStrategy);
jpaProperties.put("hibernate.search.backend.analysis.configurer", "class:config.EnhancedLuceneAnalysisConfig");
jpaProperties.put("hibernate.search.backend.uris", elasticSearchHostAddress);
jpaProperties.put("hibernate.search.backend.directory.type", "local-filesystem");
jpaProperties.put("hibernate.search.backend.type", "elasticsearch");
jpaProperties.put("hibernate.search.backend.directory.root", luceneAbsoluteFilePath);
jpaProperties.put("hibernate.search.backend.lucene_version", "LUCENE_CURRENT");
jpaProperties.put("hibernate.search.backend.io.writer.infostream", true);
EDIT:
These are all the elastic search related dependencies that my application uses.
<dependency>
<groupId>org.hibernate.search</groupId>
<artifactId>hibernate-search-mapper-orm</artifactId>
<version>6.1.5.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate.search</groupId>
<artifactId>hibernate-search-backend-elasticsearch-aws</artifactId>
<version>6.1.5.Final</version>
</dependency>
Heres the stacktrace,
[ERROR] 2022-07-21 14:33:58.402 [es_rest_client_sniffer[T#1]] Sniffer - error while sniffing nodes
java.net.ConnectException: Connection refused: no further information
at org.elasticsearch.client.RestClient.extractAndWrapCause(RestClient.java:918) ~[elasticsearch-rest-client-7.17.3.jar:7.17.3]
at org.elasticsearch.client.RestClient.performRequest(RestClient.java:299) ~[elasticsearch-rest-client-7.17.3.jar:7.17.3]
at org.elasticsearch.client.RestClient.performRequest(RestClient.java:287) ~[elasticsearch-rest-client-7.17.3.jar:7.17.3]
at org.elasticsearch.client.sniff.ElasticsearchNodesSniffer.sniff(ElasticsearchNodesSniffer.java:106) ~[elasticsearch-rest-client-sniffer-7.17.3.jar:7.17.3]
at org.elasticsearch.client.sniff.Sniffer.sniff(Sniffer.java:209) ~[elasticsearch-rest-client-sniffer-7.17.3.jar:7.17.3]
at org.elasticsearch.client.sniff.Sniffer$Task.run(Sniffer.java:140) ~[elasticsearch-rest-client-sniffer-7.17.3.jar:7.17.3]
at org.elasticsearch.client.sniff.Sniffer$1.run(Sniffer.java:81) ~[elasticsearch-rest-client-sniffer-7.17.3.jar:7.17.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.net.ConnectException: Connection refused: no further information
at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvent(DefaultConnectingIOReactor.java:174) ~[httpcore-nio-4.4.15.jar:4.4.15]
at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:148) ~[httpcore-nio-4.4.15.jar:4.4.15]
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:351) ~[httpcore-nio-4.4.15.jar:4.4.15]
at org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.execute(PoolingNHttpClientConnectionManager.java:221) ~[httpasyncclient-4.1.5.jar:4.1.5]
at org.apache.http.impl.nio.client.CloseableHttpAsyncClientBase$1.run(CloseableHttpAsyncClientBase.java:64) ~[httpasyncclient-4.1.5.jar:4.1.5]
... 1 more
This stacktrace was copied after i had removed <elasticsearch.version>7.16.3</elasticsearch.version> so see whether that would solve the problem. If the version is missing hibernate search seems to default to version 7.17.3
It took a while but i finally found the source of the problem.
Apparently spring boot has a built-in autoconfiguration class for Elastic search called ElasticsearchRestClientAutoConfiguration. The code in this class is run by default and it initializes a org.elasticsearch.client.RestClient that that has a node sniffer enabled by default. If no elastic search server is running on localhost this RestClient will keep throwing exceptions because there is nothing to connect to.
Because this class is not part of the hibernate search java library settings such as hibernate.search.backend.discovery.enabled = false do not influence this RestClient or its Sniffer.
You can prevent Spring from creating this RestClient by telling Spring not to run ElasticsearchRestClientAutoConfiguration. This can be done in two ways.
Firstly you can add the following property to your application.properties:
spring.autoconfigure.exclude = org.springframework.boot.autoconfigure.elasticsearch.ElasticsearchRestClientAutoConfiguration
Second, you can also exclude this autoconfiguration class by adding it as a value to the exclude argument of the #SpringBootApplication annotation. For instance:
#SpringBootApplication(exclude ={ElasticsearchRestClientAutoConfiguration.class})
public class MyConfiguration {
Hibernate Search will only enable node discovery (create a sniffer) if the configuration property hibernate.search.backend.discovery.enabled is set to true, and by default it's false.
If the properties you listed are the only ones you set, then I don't think Hibernate Search is creating this sniffer. The sniffer also doesn't use the URIs you passed to Hibernate Search, so that as well tends to prove the sniffer is not created by Hibernate Search.
If you don't believe me, see by yourself by starting your app in debug mode and putting a breakpoint in org.hibernate.search.backend.elasticsearch.client.impl.ElasticsearchClientFactoryImpl#createSniffer.
I think you probably have something else in your application creating an Elasticsearch client and a sniffer, and that something else is not completely configured. Try launching your application in debug mode and putting breakpoints in the constructors of org.elasticsearch.client.sniff.Sniffer?

Keycloak / SpringBoot - The Issuer <https://example.com> provided in the OpenID Configuration did not match the requested issuer <https://bar.com>

I have an issue with a project I just join.
The technical stack :
Jhipster with Angular and SpringBoot
Keycloak
I replace the right url by example.com and bar.com
application.yaml
The endpoint https://bar.com/auth/realms/artemis/.well-known/openid-configuration returns this :
{
"issuer": "https://example.com/auth/realms/artemis",
"authorization_endpoint": "https://example.com/auth/realms/artemis/protocol/openid-connect/auth",
"token_endpoint": "https://bar.com/auth/realms/artemis/protocol/openid-connect/token",
"token_introspection_endpoint": "https://bar.com/auth/realms/artemis/protocol/openid-connect/token/introspect",
"userinfo_endpoint": "https://bar.com/auth/realms/artemis/protocol/openid-connect/userinfo",
"end_session_endpoint": "https://example.com/auth/realms/artemis/protocol/openid-connect/logout",
"jwks_uri": "https://bar.com/auth/realms/artemis/protocol/openid-connect/certs",
"check_session_iframe": "https://example.com/auth/realms/artemis/protocol/openid-connect/login-status-iframe.html",
}
When I run the App I got this error :
Caused by: java.lang.IllegalStateException: The Issuer "https://example.com/auth/realms/artemis" provided in the OpenID Configuration did not match the requested issuer "https://bar.com:8443/auth/realms/artemis"
at org.springframework.security.oauth2.client.registration.ClientRegistrations.fromOidcIssuerLocation(ClientRegistrations.java:76)
at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getBuilderFromIssuerIfPossible(OAuth2ClientPropertiesRegistrationAdapter.java:84)
at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getClientRegistration(OAuth2ClientPropertiesRegistrationAdapter.java:60)
at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.lambda$getClientRegistrations$0(OAuth2ClientPropertiesRegistrationAdapter.java:53)
at java.util.HashMap.forEach(HashMap.java:1289)
at org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientPropertiesRegistrationAdapter.getClientRegistrations(OAuth2ClientPropertiesRegistrationAdapter.java:52)
at org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientRegistrationRepositoryConfiguration.clientRegistrationRepository(OAuth2ClientRegistrationRepositoryConfiguration.java:55)
at org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientRegistrationRepositoryConfiguration$$EnhancerBySpringCGLIB$$c9d328e3.CGLIB$clientRegistrationRepository$0(<generated>)
at org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientRegistrationRepositoryConfiguration$$EnhancerBySpringCGLIB$$c9d328e3$$FastClassBySpringCGLIB$$1d0ccf00.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:363)
at org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientRegistrationRepositoryConfiguration$$EnhancerBySpringCGLIB$$c9d328e3.clientRegistrationRepository(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
... 92 common frames omitted
I'm new with Spring Boot. I don't really understand what I have to do to be able to use 2 differents url.
Thx for the help ! I can give you more informations if you need.
Your application.yaml config issuer-uri is not matching issuer of used OIDC Keycloak realm. Set it to https://example.com/auth/realms/artemis and it should be fine.
-- This may not be relative to OP's case. But for other cases.
-- Just a headsup.
-- I am not a professional on this, I could be wrong, but it helped in my case.
The problem could occur from the other side, in the Authorization Server.
So, for example, you may not only need to look at the application.yml in the Resource Server:
spring.security.oauth2.resourceserver.jwt.issuer-uri: http://localhost:9999
you may also need to look at the Authorization Server:
#Bean
public ProviderSettings providerSettings() {
return new ProviderSettings().issuer("http://localhost:9999");
}

java.lang.NumberFormatException: For input string: "443,80"

I am getting the following exception while hitting my backend Spring boot application which is deployed on a Kubernetes container:
java.lang.NumberFormatException: For input string: "443,80"
All my services are registered with eureka:
#Eureka
spring.application.name=app-name
eureka.client.registerWithEureka=true
eureka.client.fetchRegistry=true
eureka.client.serviceUrl.defaultZone=http://app-eureka-dev/eureka
eureka.instance.preferIpAddress=true
eureka.instance.non-secure-port-enabled=true
And all my requests are routed through ingress/zuul services.
spring.application.name=app-gateway
eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=true
eureka.client.serviceUrl.defaultZone=http://app-eureka-dev/eureka
When we try hitting backend services from the Swagger API, I am getting below exception.
java.lang.NumberFormatException: For input string: "443,80"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.parseInt(Integer.java:615)
at springfox.documentation.swagger2.web.HostNameProvider.componentsFrom(HostNameProvider.java:72)
at springfox.documentation.swagger2.web.Swagger2Controller.getDocumentation(Swagger2Controller.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod
I am connecting to the eureka service through the container name, even though I am getting above exception. Is there any other configuration required, as we do ssl offloading in ingress, rest should be plain http or unsecure calls within the container services.
This should have been fixed with Springfox 2.7.0, as can be seen in this GitHub issue and the release notes of this version.
Before Springfox 2.7.0, the following code was used to determine the port number in HostNameProvider:
String port = request.getHeader("X-Forwarded-Port");
if (hasText(port)) {
builder.port(Integer.parseInt(port));
}
So basically it used the X-Forwarded-Port header to determine the port number. However, in your case it seems like it passes both the HTTP and HTTPS ports (443,80), which is obviously not a valid integer.
Upgrading your springfox-swagger2 dependency to 2.7.0 (or higher) should do the trick.
I experienced the same problem in SWAGGER when my DTO properties annotated with #APIModelProerty. Majorly, the problem occurred when Long type properties are present in the DTO object and failed to convert the empty string ("") value into 0.
So, it solved when I added example property in #APIModelProperty(example = "1", required = "false").

Connection is not associated with a managed connection , "Spring application in Jboss Server"

Below Exception is coming in specific server, issue is not consistent.
org.springframework.jdbc.support.MetaDataAccessException: Error while extracting DatabaseMetaData; nested exception is java.sql.SQLException:
Connection is not associated with a managed connection.org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6#49828f4c
at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:296)
at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320)
at org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:213)
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141)
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.<init>(SQLErrorCodeSQLExceptionTranslator.java:104)
at org.springframework.jdbc.support.JdbcAccessor.getExceptionTranslator(JdbcAccessor.java:99)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:969)
at org.springframework.jdbc.core.JdbcTemplate.call(JdbcTemplate.java:1003)
at org.springframework.jdbc.object.StoredProcedure.execute(StoredProcedure.java:144)
at com.watsons.tfo.sp.dao.SPSaveTransactionDetail.execute(SupplierPromotionDaoImpl.java:3354)
at com.watsons.tfo.sp.dao.SupplierPromotionDaoImpl.savePromoTransaction(SupplierPromotionDaoImpl.java:422)
at com.watsons.tfo.sp.service.SupplierPromotionServiceImpl.savePromoTransaction(SupplierPromotionServiceImpl.java:158)
at sun.reflect.GeneratedMethodAccessor1010.invoke(Unknown Source)
--
org.springframework.dao.RecoverableDataAccessException: CallableStatementCallback; SQL [{call PKG_TFO_SUPPLIER_PROMOTION.PR_INS_SAVE_TRANSACTION_DET(?, ?)}]; No more data to read from socket; nested exception is java.sql.SQLRecoverableException: No more data to read from socket
at com.watsons.tfo.sp.service.SupplierPromotionServiceImpl.savePromoTransaction(SupplierPromotionServiceImpl.java:160)
at sun.reflect.GeneratedMethodAccessor1010.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy206.savePromoTransaction(Unknown Source)
at com.watsons.tfo.sp.controller.SupplierPromoTransactionController.saveSupplierPromoTransaction(SupplierPromoTransactionController.java:1077)
at com.watsons.tfo.sp.controller.SupplierPromoTransactionController$$FastClassByCGLIB$$8994f9f9.invoke(<generated>)
First i thought the is because of stale connection, So I have added stale connection checker in the oracle-ds.xml. But again the issue is came up
Please help me to resolve this.
Disabling the CachedConnection Manager
<Valve className="org.jboss.web.tomcat.tc5.jca.CachedConnectionValve"
cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager"
transactionManagerObjectName="jboss:service=TransactionManager" />
The above tag is mentioned in server.xml. this cachedconnectionvalve should be turned off in production server.
There are two main configuration parameters that have a direct effect on performance and scalability: cached connection manager and HTTP session replication.
The CachedConnectionManager is configured to be in the servlet container in debug mode. It's also configured in the production configuration but with debug mode off.
I commented the CachedConnectionValve at end of the server.xml file.
Also commented the CachedConnectionManager in META-INF/jboss-service.xml.
The "Connection is not associated with a managed connection" is gone and application is running fine.
Update:
Found one more log for the same error in the oracle log files...
Oracle version: Oracle Database 11.2.0.2
i.e XMLSEQUENC/EEXTRACT FAILS WITH ORA-7445[__INTEL_NEW_MEMCPY()+5395]
This is the bug with the XML Processing in oracle DB version, Then
After instructed by oracle people, Updated the patch (11666959) for oracle .
Same is mentioned in oracle web site.
11666959 is required for the release utility; XMLSEQUENC/EEXTRACT FAILS WITH ORA-7445[__INTEL_NEW_MEMCPY()+5395] IN 11.2.0.2

EhCache terracottaConfig url in https

Can I work with secured environments (eg. HTTPS) using Terracota server Arrays ?
I 've tried to configure ehcache.xml file like this:
<terracottaConfig rejoin="true" url="https://localhost:9510,https://localhost:9511"/>
But it remains in error.
Caused by: java.lang.IllegalArgumentException: URI can't be null.
at sun.net.spi.DefaultProxySelector.select(DefaultProxySelector.java:116) ~[na:1.6.0_23]
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911) ~[na:1.6.0_23]
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841) ~[na:1.6.0_23]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177) ~[na:1.6.0_23]
at com.tc.config.schema.setup.sources.ServerConfigurationSource.getInputStream(ServerConfigurationSource.java:42) ~[na:na]
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.trySource(StandardXMLFileConfigurationCreator.java:343) ~[na:na]
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.getConfigDataSourceStrean(StandardXMLFileConfigurationCreator.java:289) ~[na:na]
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.loadConfigDataFromSources(StandardXMLFileConfigurationCreator.java:222) ~[na:na]
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.loadConfigAndSetIntoRepositories(StandardXMLFileConfigurationCreator.java:120) ~[na:na]
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.createConfigurationIntoRepositories(StandardXMLFileConfigurationCreator.java:102) ~[na:na]
at com.terracotta.express.StandaloneL1Boot.resolveEmbedded(StandaloneL1Boot.java:177) ~[terracotta-toolkit-1.5-runtime-4.2.0.jar:na]
at com.terracotta.express.StandaloneL1Boot.resolveConfig(StandaloneL1Boot.java:122) ~[terracotta-toolkit-1.5-runtime-4.2.0.jar:na]
... 106 common frames omitted
If it is possible what is the way to do this?
Simply put Terracotta doesn't support cluster communication over SSL currently. If you are using the commercial edition you have an additional layer of security because a client won't be able to connect to the cluster if it doesn't have the correct license key. Apart from that you can use firewall rules to restrict access.

Resources