I have 2 nodes running in HA mode having common databases and artifacts synchronised. First node shows all the APIs (total-5) but second node shows only 4 ... one API is not being displayed on publisher page of second node. How should I resolve this issue what should I check here ? Is there any back-end directories where publisher stores data of this API ?
Related
Upon implementing WSO2 EI Clustering and LoadBalancing with Apache on 2 nodes, the routing and functioning of EI management console goes well when only one node is up.
When the 2 nodes are up , the management console behaves unexpectedly (displays home page with missing parts, logout when clicking on any link like list of users,…)
the EI logging displays the following:
WARN - AuthenticationHandler Illegal access attempt at [2023-01-04 18:09:18,0700] from IP address null while trying to authenticate access to service RegistryAdminService
[2023-01-04 18:09:18,708] [EI-Core] ERROR - RegistryAdminServiceClient Error occurred while checking registry mode
log in to the management console and navigate inside
While load testing, after some successful responses from the API, JMeter records errors:
'Premature end of Content-Length delimited message body'.
From logs inside the code the response seems to complete normally.
The APP is deployed on AKS with ingress nginx/1.15.10 controllers. The APP consists of 4 separate APIs (one master calling the 3 others). The APIs are created in FLASK with CONNEXION and run in a WSGIContainer on a Tornado HTTPServer.
Another confusing factor is that the APP is deployed on two AKS instances on the same cluster. The one deployment does not return errors and the other does.
What could be causing the error?
I would suggest to limit your testing scope.
1) target the application directly (bypassing the k8s svc and ingress controller). ensure you target each app running on the two different nodes. Do you still see the issue ?
2) target the app service directly (bypassing ingress controller), ensure you target each app running on the two different nodes. Do you still see the issue ?
3) target the app using its ingress, ensure you target each app running on the two different nodes. Do you still see the issue ?
Based on those results, we should be able to pinpoint better the source of your issue.
Traffic Distributor (https://docs.jelastic.com/traffic-distributor) is a cool feature which add's load balancing to your app and enables Blue/Green deploy.
However, seems that there's no API to control traffic distributor so it's impossible to automate new releases rollout.
Is there a way to do this?
There is a possibility to create and control Traffic Distributor via API.
Let us explain the flow...
At first, you should login to the platform and get your session.
This can be done by next API request:
https://app.{platform_domain}/1.0/users/authentication/rest/signin/login={your_email}&password={your_password}
If you are using Jelastic platform v5.1+ you should perform the mentioned request as POST.
As example, you can do this using curl:
curl 'https://app.{platform_domain}/1.0/users/authentication/rest/signin' -d "login={your_email}&password={your_password}"
Next, you can create the Traffic Distributor using this request:
http://appstore.{platform_domain}/InstallApp?envName=[env_name]&session=[your_session]&jps=traffic-distributor&displayName=[disp_env_name]&settings={"extip":true,"balancerCount":1,"routingMethod":"round-robin","range":50,"backend1":"{environment_1}","backend2":"{environment_2}"}
, where
[env_name] - the name of the environment.
[disp_env_name] - the visible name of the environment in the Dashboard.
[your_session] - your session, which can be taken from the response of the previous request.
The necessary settings of the Traffic Distributor can be specified inside the JSON:
extip - enables the external IP for the Traffic Distributor ( Highly recommended! ).
balancerCount - count of the balancers inside the Traffic Distributor. (by default = 1)
routingMethod - defines the necessary method of the traffic's routing.
You can specify next possible values: round-robin, sticky-sessions or failover
range - define the percent of the traffic, that will be routed to the first environment.
For example:
0 - All requests will be routed to the {environment_2},
100 - All requests will be routed to the {environment_1},
50 - All requests will be balanced between environments equally.
{environment_1} - URL to the first environment like env-XXXXXXX.{platform_domain}
{environment_2} - URL to the second environment like env-XXXXXXX.{platform_domain}
After executing this method - Traffic Distributor will appear in the Jelastic Dashboard.
Please, execute next API request to take the "uniqueName" value from the response (inside the Addons section):
https://app.{Platform_domain}/1.0/environment/control/rest/getenvinfo?envname=[env_name]&session=[your_session]
, where [env_name] - the name of the created environment with the Traffic Distributor addon.
Now you can control the settings of the created Traffic Distributor by next API:
https://appstore.{Platform_domain}/ExecuteAppAction?session=[your_session]&appUniqueName=[app_unique_name]&action=configure¶ms={"extip":1,"balancerCount":1,"routingMethod":"sticky-sessions","range":50,"backend1":"{environment_1}","backend2":"{environment_2}"}
, where
[app_unique_name] - the value "uniqueName" from the response of the previous request.
The settings inside the JSON exactly the same as for the InstallApp API request.
I have a gatewaymanager (GWM) with 2 worker nodes. When I deploy an API its pushed to the GWM and is available threre --> API-Call works fine.
I decided to synchronize the APIs from the GWM to the worker nodes via rsync. The filesystems under ~wso2/repository/deployment/server on the workernodes are synced and similar to the GWM node.
But when I call the API on a worker node I get this message:
<am:fault xmlns:am="http://wso2.org/apimanager"><am:code>404</am:code>
<am:type>Status report</am:type><am:message>Not Found</am:message>
<am:description>The requested resource (/XXX/1/foo) is not available.
</am:description>
</am:fault>
I also restarted the workes, but same result.
Did I miss something or is there a trigger to load the APIs on the workers to the cache, or something like this?
Faced same issue , when the contents of mediation files were changed.
**Solution which worked for me **
Demote your api to created
Ensure gateway is checked
Redeploy it
We are maintaining an application which uses Jboss as its AS. Recently customer complained about OOM error and he was unable to login. We restarted Jboss and added configurations to collect heapdump.
Customer's application usage pattern: Customer opens a page containing 10 charts which are rendered in an inframe. Flex is used for UI. This page refreshes itself every 5 minutes.
Request Flow: The application is built in such a way that all the requests go through Apache (Http) proxy server. Every 5 minutes the dashboard request has to pass through Apache proxy server.
After 5 days OOM error occurred and on analyzing the heapdump we noticed that the error was due to "org.apache.catalina.session.StandardSession", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70" occupy 1,776,569,336 (87.71%) bytes.
Full description is:
847,599 instances of "org.apache.catalina.session.StandardSession", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70" occupy 1,776,569,336 (87.71%) bytes. These instances are referenced from one instance of "org.apache.catalina.Session[]", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70"
Keywords
org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70
org.apache.catalina.session.StandardSession
org.apache.catalina.Session[]
Common Path To the Accumulation Point says:
java.lang.Thread # 0x7b4a5f358 ContainerBackgroundProcessor[StandardEngine[jboss.web]]
org.apache.catalina.session.StandardSession # 0x797b49b70
I am new to Jboss and proxy servers. How to debug this issue? Could you please help me.
Thanks
M
org.apache.catalina.session.StandardSession is a class representing user http session. I would say, that your every request creates new http session on JBoss which is never expired. Either pass session cookie back to JBoss with every refresh to reuse sessions and not to create new ones. Or configure sensible http session expiration policy in you JBoss.
Good luck,
Plumbr team