LDAP connection reset timer - ldap

I am creating LDAP connection using initialldapcontext.
I see there is option like
jndi.ldap.read.timeout - time to wait for read operation
jndi.ldap.connect.timeout - time to wait for connect operation.
I have a requirement where the ldap connection is active but still I have terminated it based on a timer.
For exmaple: there are three ldap server and there is time 5 min. So once a ldap connection is opened it has to be active only for 5 min then it should terminate and then reconnect.
It is some thing like maximum session time for a ldap session.
Whether there is any flag like jndi.ldap.read.timeout or jndi.ldap.connect.timeout for this purpose.
Thanks in advance.

I would suggest using a connection pool. The JNDI LDAP provider documentation shows that there is a system property called com.sun.jndi.ldap.connect.pool.timeout which would do the disconnect part for you. Not the automatic reconnect, though. However, establishing a new connection should not be very expensive (unless you really need to optimize for speed/scale).
The UnboundID LDAP SDK (disclaimer: I work for UnboundID) has more flexible options. See the LDAPConnectionPool class for more details.

Related

Best way to kill ZK session correctly

I am using ZK framework on server. Also, I use Spring Security and home grown security server.
Session timeout in Servlet container - 3600 seconds.
Session timeout in security server - also 3600 seconds.
Sometimes security server's session fils, but ZK session is still alive. I wrote servlet filter to intercept requests and check security server's session for availability.
So, I can intercept request to /zkau, but it's POST request and during redirect ZK shows error message box, with message about server connection error.
Does anyone knows, is there any way to tell ZK that it's session needs to be destroyed?
Best regads and thanks for wasting your time.
I suppose you kill session immediately during POST request to /zkau. Interface org.zkoss.zk.ui.Session has two methods to make session invalidated: invalidate and invalidateNow. The former method just sets the flag that indicates that session is invalid and native session will be invalidated on next request. I believe this is what you need.

Weblogic datasource test connection on startup

We have multiple data sources in our weblogic(10.3.5) connecting to different DB servers (we have quite a few DB servers).
If any one of the DB server is down or the DB password changed/expired, the complete managed server is going to admin state.
I think this is because weblogic is trying to test the datasource while its coming up and since its unable to initialize the datasource, the server is not starting and going into admin mode.
Is there a way we can disable this feature? Our application has a logic to check the datasource if it is active (test connection) before the user starts using that datasource.
I am aware of weblogic JMX MBeans which can be used to disable/suspend. But to do this, we need to write a startup class. Not sure if this works, but If there's a configuration that we can set, we would prefer that.
On the Connection Pool tab for the datasource, set the Initial Capacity to 0. This will stop the initial check and the server should start properly.

IBM Worklight - Connecting/Re-Connecting: WL.Client.connect vs. connectOnStartup vs. WL.Client.invokeProcedure

In our project we are trying to figure our what the best process to connect to the server will be - especially when taking care of offline/online scenarios etc.
Right now, for us, it seems that all three options to connect to the WL server are similar. Whatever option we use, we can call our Adapter Procedures perfectly and we receive Notification Messages that are set in the console.
We are not sure about Direct Update - this is not working properly yet.
Are there any important differences between these three ways of connecting to the WL server, or is basically the same connection procedure being executed in all three cases?
How about WL.Client.init() before connecting - could we call that again (in addition to the standard window load EventListener) in our code before we connect using a WL.Client.connect manually - or is init() supposed to be called only once?
Tied to that is also offline and re-connecting.
As far as I have read in the tutorials, the WL Client framework is managing the connection state. Does that mean that when the WL client is connected to the server through any of these three ways and loses it's WLAN/3G/4G connection (or it's access to the WL server due to internet connection blocker or so) it re-connects automatically (regularly tries to re-connect until successful) when a connection to the WL server is available again?
EDIT
I was thinking about Events or Threads that provide more low-level information (not WORKLIGHT_IS_CONNECTED) - basically events that would be triggered when the device loses/gets WIFI/3G/4G connection and/or internet connection. Or is there only polling using WL.Device.getNetworkInfo() available?
Would the use of Cordova Event like:
document.addEventListener("offline", yourCallbackFunction, false);
provide a functionality close to that?
Though those three ways do have some similarities the differences between them are very important.
WL.Client.init() initializes client side WL framework.
WL.Client.connect() triggers connection request to WL server.
initOptions.connectOnStartup defines whether WL.Client.connect() will be invoked automatically during WL.Client.init().
In general - most of the functionality (e.g. adapters, remote disable) will function even if you call WL.Client.invokeProcedure() without calling WL.Client.connect(). But there are several things that will not function:
You will not be able to fully utilize push notifications without calling WL.Client.connect()
Direct update is triggered during WL.Client.connect()
WL.Client.connect() will get security related info from server, e.g. names of realms, whether user authenticated in those realms etc. Therefore all APIs like WL.Client.getUserInfo, .isAuthenticated(), .getUserName() etc will not function.
It is strongly recommended to start your session with WL.Client.connect() (or initOptions.connectOnStartup=true).

LDAP Connections

I have a very basic question about the LDAP Protocol:
Can a client be connected for an undefined period of time or each authentication requires to open and close a tcp connection?
Professional-quality LDAP servers can be configured to terminate clients after a period of time, a maximum number of operations, or other conditions; or alternatively, leave the the client connected forever. Ask your LDAP server administrator whether client connections are being terminated for any of the conditions listed, or perhaps others.
In addition to what Terry says, professional quality LDAP client APIs use a connection pool to hide all these gory details from you; to keep connections open as long as possible; and to recover from situations where the server imposes a connection termination rule.
LDAP servers may implement multiple limits on the server side , The LDAP client APIs also provide options to set limits at the client side. Some of the server side limits are [ In case of Oracle DSEE]
Size limit - Number of searh result entries returned
Time limit - Time taken to process the request
Idle time Limit - How much time the connection can stay idle ? [keepalive at load balancers can keep the connection alive] . server access log marks connections closed because of idle time .
Lookthrough limit - Number of candidate entries to look through for a given ldap search
Client APIs may set it's own time and size limit

Weblogic connection pool

Whenever I change connection pool parameters (url, id, pwd etc) I try to deploy the new connection pool in weblogic using the Control tab. I do a shutdown and start which IMO should redepoly the new connection pool.
But the changes take effect only when I restart the server. What other parameters need to be tuned to avoid restarting the server?
Thank you!
You need to untarget and retarget that specific connection pool to the server or cluster, that should be enough.
You dont have to restart the whole WL server.
Some settings require reset (or redeploy) and some don't.
To find out which option requires restart/redeploy you should click on [More info ...] near option description (or go to
JDBC Data Source -> Configuration -> Connection Pool)
In example, you will find out that Maximum Capacity does not require restart.
But for Pinned-To-Thread option it says:
Changes take effect after you redeploy the module or restart the server.