I have gemfire client server configured via gfe based xml. The locator, cache server and client cache start through these xml configurations. I populate my Region by getting data from database. The client uses data from this Region. It works very well for about 2 hours but after that the client starts throwing following exception and trace.
I don't do any changes to running application. That means the locator and cache server should be running at all times. Any help would be great. Thanks.
com.gemstone.gemfire.cache.client.NoAvailableLocatorsException: Unable to connect to any locators in the list [/locator-host:locator-port]
at com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
at com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:205)
at com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:418)
at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:114)
at com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:638)
at com.gemstone.gemfire.cache.client.internal.GetOp.execute(GetOp.java:89)
at com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:126)
at com.gemstone.gemfire.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2767)
at com.gemstone.gemfire.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1605)
at com.gemstone.gemfire.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:133)
at com.gemstone.gemfire.internal.cache.LocalRegion.get(LocalRegion.java:1489)
at com.gemstone.gemfire.internal.cache.LocalRegion.get(LocalRegion.java:1451)
at com.gemstone.gemfire.internal.cache.AbstractRegion.get(AbstractRegion.java:278)
Do you have anything in your locator or server logs? That exception indicates the client is trying to create a new connection and can't connect to a locator.
If your locator goes down, the client might still be able to work for a while using it's existing connections because it doesn't need to go back to the locator until it needs a new connection.
Related
I have a requirement where I have configured 'min-connctions= number of client thread * number of geode cache server'.
so that during load there will be not connection while accessing the connection or no new connection is needed if all threads start accessing to a single Server.
the problem is that it is locator who decide the how many connection client can create to a server JVM based on load probe.
I want to ignore everything just wanting equal number on Connections to all Cache Server JVMs.
I had Apache Geode cluster running and I was connected to it using gfsh client. In order to test something, I stopped the Cache Server using, "stop server --name=xxxxserver" command. The Cache server stopped successfully.
Further, I stopped the locator using the "stop locator --name=xxxxlocator" command. The locator stopped successfully. However, my gfsh client connection was also disconnected.
Now, I am trying to reconnect my gfsh client to the locator, but it always gives me a 502 bad gateway error. I have tried accessing the pulse url, I get the same error:
"502 Bad Gateway: Registered endpoint failed to handle the request."
What I am missing and how can this be fixed?
If you stopped your locator, it's expected for gfsh and PULSE to be disconnected as there's no JMX Manager they can talk to. You should start your locator again and re-connect, then everything should be fine.
Cheers.
Right. But, the problem is I am unable to start the locator due to the error I have mentioned. I created another cache instance to verify, but don't see this problem. Stopped/started locator with no issues and able to access the pulse as well.
What's needed to run multiple gemfire/geode clusters on one machine? I'm trying to test using WAN gateways locally, before setting it up on servers.
I have one cluster (i.e. gemfire.distributed-system-id=1) up and running with one locator and one server.
I am trying to setup a second cluster (i.e. gemfire.distributed-system-id=2), but receive the following error when attempting to connect to the locator in cluster 2:
Exception caused JMX Manager startup to fail because: 'HTTP service
failed to start'
I assume the error is due to a JMX Manager already running in cluster 1, so I'm guessing I need to start a second JMX Manager on a different port in cluster 2. Is this a correct assumption? If so, how do I setup the second JMX Manager?
Your assumption is correct, the exception is being thrown because the first members started some services (PULSE, jmx-manager, etc.) using the default ports already
You basically want to make sure the properties http-service-port and jmx-manager-port (non an extensive list, there are other properties you need to look at), are different in the second cluster.
Hope this helps.
Cheers.
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.
Hi I have a application that is deploy on two weblogic app servers
recently we have issue that for certain cases the user session returned is null. Developer feedback is that it could be caused by the session not replicating to the other server.
How do we prove if this is really the case?
Are you using a single session store that both application servers can access via some communication protocol? If not, then it is definitely the case. Think about it, if your weblogic servers are storing the session in memory anywhere, and having users pass their session id via cookies, than the other server has no way of accessing the memory on the other machine. Unless you are using sticky load balancing. Are you?
There's 2 concepts to consider here - Session stickiness and session replication.
Session Stickiness is a mechanism where weblogic server ensures that if a request from a user with session A goes to server 1 then the next request from user with session A will go to server 1 only.
This is achieved by configuring a hardware loadbalancer (like F5) which is capable of providing session stickiness. or configuring weblogic proxy installed on apache/iis/weblogic.
The first time a request reached WLS managed server, it responds with a session id and appends to it the JVM id of the server (this is the primary id), if the managed server is part of a cluster, it also attaches a secondary server jvm id (the secondary server is the server where the session is being replicated)
The proxy maintains a table of all JVM id's and corresponding IP of managed server, it also checks periodically if the servers are up and running or not.
The next time when another request passes the proxy with existing session id and a primary jvm id, the proxy parses this and tries to send the request to that server, if it cannot within some time it tries to send to secondary server.
Session Replication - This is enabled by default when you configure a WLS cluster with 2 or more managed server. Each time any data is updates to a session, its data is replication in a secondary server too.
So in your case if your application users are loosing session or getting redirected to login page between normal usage, then check that the session did not get invalidated because of a timeout, if you have defined a cluster and using WLS proxy then check the proxy debug output to make sure the primary and secondary server are being appended to the session id.
Finally there's a simple example in the sample application deployment of wls that you can use to test session replication and failover functionality.
So to prove why session is getting lost,
1) check server log to see if session got invalidated because of timeout,
2) if using wlproxy, enable debug, and the next time the issue happens check in the proxy log if the request was sent to a different server, and if that server is not the secondary server.