When configuring a JDBC Datasource in the configuration file for CORDA, could a database connection pool be used such as the Apache Commons connection pool used on Java application servers? Would this even provide any advantage since CORDA itself might be providing object pooling for the node?
Corda already uses HikariPool so it wouldn't provide an advantage
Related
I am try planning to introduce Apache Ignite into existing old .net web api project to use it as key/value store for detecting duplicate requests sent to the load balanced api.
I would like to introduce minimum overhead to each request.
As I understand Client node is communicating to the server through TCP.
My current go to plan is to create a singleton object which will establish connection to the remote cache and register it in my DI container.
Is it ok to leave node running and TCP connection open or should make the ignite object scoped to start close on each request/response cycle?
Keep in open, as a singleton.
Ignite object is thread safe
It is expensive to create and connect to the cluster (in case of classic "Thick" client)
There is also a "Thin" client, which is very lightweight and can be created and disposed often. Note that thin client is also thread safe.
Also, you can try to use REST:
https://apacheignite.readme.io/docs/rest-api
The C# IgniteSessionStateStoreProvider appears to be launching an entire instance of a JVM in-process in order to run a ignite node. I was wondering if it would be feasible to create a lightweight provider that talks to the cluster nodes, but that isn't a full node itself, i.e. doesn't require an in-process JVM.
By feasible I mean is there some fundamental architectural reason why there can't be a lightweight/thin provider?
is there some fundamental architectural reason why there can't be a lightweight/thin provider
We just used Ignite.NET API to create the provider, and that API starts a JVM in process. Advantage is this works very fast.
Thin client mode is coming in Ignite.NET 2.4 (expected in January). I've filed a ticket to add thin session store: https://issues.apache.org/jira/browse/IGNITE-7269
The current app (with a competitor) is using Spring-Boot and Spring-Sessions to save session data independent from the instance in Redis.
How can we replicate this in Bluemix?
Is there a way to add on Spring-Sessions to the Redis service?
The other option would be the IBM Session Cache. Does that work with Spring-Boot and Spring-Session? Does the Session Cache service work without Tomcat? (Jetty for example?)
I haven't played with Spring-Sessions yet, but I might be able to point you in the right direction.
There is a general Redis service available on Bluemix. The open source Java buildpack (Tomcat) promises auto configuration of Redis. I would try this first. To use this buildpack:
cf push <appname> -b java_buildpack
If that doesn't work, you could read the credentials from VCAP_SERVICES and configure JedisConnectionFactory programmatically connect to it.
If you use the IBM Session Cache service with a Liberty application on Bluemix, the configuration is auto generated such that standard JEE HTTPSession objects are persisted to the service. It might work with other java runtimes, but configuration would be more manual.
Hope this helps.
Does the session cache work without Tomcat (Jetty for example)?
In general, the session cache should work with any webserver/servletcontainer, when Bluemix supports Jetty runtime for example, the session cache should support.
Session cache is based on IBM WebSphere eXtreme Scale caching technology, and the base product had been tested against WebSphere, Liberty and Tomcat runtime for the HTTP session use cases, but not tested under Jetty.
Spring documentation says that Spring Session can transparently leverage Redis to back a web application’s HttpSession when using REST endpoints.
Does anyone know if Spring supports GemFire in this place instead of Redis to back a web application's HttpSession ?
Ref: http://docs.spring.io/spring-session/docs/current/reference/html5/guides/rest.html
Not yet, ;).
However, I did spend a little time researching the effort involved to implement a GemFire adapter for Spring Session to back (store/replicate) an HttpSession. I still need to dig a little deeper and I will be tracking this effort in JIRA here (SGF-373).
Also know that GemFire already has support for HTTP server session replication using GemFire's HTTP Session Management Module.
Will post back when I have more details.
Will these 3 steps (at a high level) be sufficient to allow Spring Session to write to Gemfire repository instead of Redis ?
Step 1: Implement just a Configuration class which provide all functions as the annotation
Allow spring to Load the configuration class
Register Spring Session Filter in Container
Establish Repo Connection Factory
Repo connection configuration
we will continue to re-use the Spring Session’s springSessionRepositoryFilter
Step 2: Need to develop an equivalent GemfireOperationsSessionRepository implementing the interface SessionRepository
Step 3: SessionMessageListener.java
3.1. Need to decide a technique to identify and save delta changes in Session to underlying repository
3.2. Need to see how session expire notification from underlying repository can be captured to invoke SessionDestroyEvent and cleanup operations -
We are trying using HornetQ for messaging on Jboss AS 7.1 and the documentation at
https://docs.jboss.org/author/display/AS71/Messaging+configuration
says
There is also a pooled-connection-factory which is special in that it leverages the outbound adapter of the HornetQ JCA Resource Adapter. It is also special because:
* It is only available to local clients, although it can be configured to point to a remote server.
* As the name suggests, it is pooled and therefore provides superior performance to the clients which are able to use it. The pool size can be configured via the max-pool-size and min-pool-size attributes.
* It should only be used to send (i.e. produce) messages.
* It can be configured to use specific security credentials via the user and password attributes. This is useful if the remote server to which it is pointing is secured.
Every thing made sense except the third bullet which says
* It should only be used to send (i.e. produce) messages.
My mdb uses Pooled connection factory and is consuming messages (Not sending).
My understanding is Pooled connection factory is what the MDB should use for better performance. Also the hornetq Author's say
http://hornetq.blogspot.com/2011/06/hornetq-on-jboss-as7.html
The pooled connection factories also define the incoming connection factory for MDB's,
the name of the connection factory refers to the resource adapter name used by the MDB,
Can some guru's throw some light on this ?
Thanks
Rama
This is something we try to make it easier for users but still some confusion.
the JCA Adapter specifies InBound Connections and Outbound connections...
InBound connections are used by MDBs and outBounds are done through using the JNDI and instantiating connections.
InBound connections don't need pooling for instance as they just instantiate the consumers for the MDBs and stay up as long as you have an MDB...
We keep definitions on the PooledConnection factories for defining the MDBs but underneath there are a few things happening as I said.
So, we could maybe reword this item you mentioned to explain that better.