Could you please assist me with the following issue.
I use Apiman version 1.2.1
FROM jboss/wildfly:9.0.2.Final
ENV APIMAN_VERSION 1.2.1.Final
I expose this version via kubernetes, as a persistent volume I use postgres in the same container. Once I create it at the first time, after this in the apiman I have added Organization/ API/.... and all necessary staff.
I press on button to publish api, and may check that it works perfect, so I use kubectl port-forward pod-name 8080:8080 and may check my gateway via browser http:localhost:8080/apiman-gateway/ORgId/bla/bla/bla/bla?givemedescriptionbyid=1.
After this one I go to console and kill apiman pod, as a result of pod restart, the same operation kubectl port-forward new-pod-name 8080:8080, and I can see that the all data of apiman like organization, apis and all other staff is already there.
But one big problem if you try to call gateway again, it tells you that:
{"responseCode":500,"message":"API not
found.","trace":"io.apiman.gateway.engine.beans.exceptions.InvalidApiException:
API not found.\n\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$3.handle(ApiRequestExecutorImpl.java:278)\n\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$3.handle(ApiRequestExecutorImpl.java:271)\n\tat
io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:122)\n\tat
io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:111)\n\tat
io.apiman.gateway.engine.es.CachingESRegistry.getApi(CachingESRegistry.java:116)\n\tat
io.apiman.gateway.engine.impl.SecureRegistryWrapper.getApi(SecureRegistryWrapper.java:111)\n\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:270)\n\tat
io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:232)\n\tat
io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet.java:77)\n\tat
javax.servlet.http.HttpServlet.service(HttpServlet.java:687)\n\tat
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)\n\tat
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)\n\tat
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)\n\tat
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)\n\tat
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)\n\tat
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)\n\tat
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)\n\tat
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)\n\tat
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)\n\tat
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
java.lang.Thread.run(Thread.java:745)\n"}
I can see, that by metrics of calls in api manager, all my calls can reach apiman-gateway, but I get 500 response code.
If anybody will met such error, so, I have solved it with the following steps, first of all we need to use only new version of APIMAN, list of fixes already implemented. And also apiman-gateway cannot live without elastic search to restore itself. Hence elasticsearch configuration should to be provided.
Related
So apologies if what I ask is trivial but I am experimenting with Memcached and Jmeter. I have a Memcached server setup (as far as I can tell) and am able to make telnet requests to it via telnet IP PORT and additionally set and get using commands set and get appropriately.
Now point me to a different application if perhaps this is the wrong choice; but my understanding was that Jmeter should allow me to pound the server with equivalent Set and Get requests.
Unfortunately the experimental platform is a remote linux PC running Rockylinux which is similar to CentOS / RedHat to my understanding (I didn't set this part up); and as a result I do not have a GUI to launch while on the Linux PC. I have however opened Jmeter up on my local PC on windows and understand I should be able to send the test file over and run it.
I followed these instructions to try to setup a TCP sampler and set the "text to send" field as below; after doing the additional step in the link regarding the precompiler.
set tutorialspoint 0 900 9${CR}${LF}
memcached${CR}${LF}
quit${CR}${LF}
Running the above as a headless jmeter session doesn't generate any errors called [./jmeter -n -t "Sample.jmx" -l testresults.jtl"] but when I connect via telnet I'm also not seeing the value for the key "tutorialspoint" get updated. When manually doing the get and set I am seeing updates. Any ideas what I could be doing wrong? Checking the log indicates ResponseCode 200 OK as expected. Is there a good method to debug something in a Headless setup?
Thanks for your time.
I believe the easiest way is using Memcached Java Client library
Download spymemcached-2.12.3.jar and drop it to "lib" folder of your JMeter installation (or any other location in JMeter Classpath)
Restart JMeter to pick the .jar up
Add JSR223 Sampler to your test plan and use the following code snippets:
def client = new net.spy.memcached.MemcachedClient(new InetSocketAddress('your-memcached-host', your-memcached-port)) - for connecting to the server
client.set('tutorialspoint', 900, 'memcached').done to write memcached to the tutorialspoint key for 15 minutes
client.get('tutorialspoint') - to read the value of tutorialspoint key
client.shutdown() - to disconnect
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It
Demo:
I am trying to use Fabric whith java shim and I am still searching how to display logs on the peer output ?
I tried this :
peer node start --logging-level DEBUG
also searching to use the logger of the parent class :
private static Log logger = LogFactory.getLog(ChaincodeBase.class);
without success. Cannot see the outputs on the peer
Does anyone has an idea ?
I found myself the solution. It implies to access the Docker image inside the peer and call :
docker logs mycontainersidwhatever
but i think is could be still buggy as I am in DEBUG mode, and I see now only WARN level for the chaincode
When you instantiate a new chaincode, the peer will create a new docker container called dev-(peer name)-(contract name)-(contract version). You can see logs direct in this container.
However, fabric java chaincode uses its own logging configuration, and it uses an environment variable called CORE_CHAINCODE_LOGGING_LEVEL to define the logging level the chaincode will use. Usually, this environment variable is set to 'info' level. You can manually update the value of this variable inside the docker container running the contract, or you can define this variable into the peer, so every contract will the the defined value to it.
In 'fabric-samples\first-network\base\peer-base.yaml' ensure you have the following before you start HLF network, and then spin up the network.
FABRIC_LOGGING_SPEC=DEBUG
This will generate logs in DEBUG mode. Now, in order to see these logs that are generated within docker contaner, we'll have to ask docker for logs, and that can be done using in a terminal window.
docker logs -f <<container-name>>
Use
docker logs container_name
Or inside your docker_compose.yaml, set logging environment
FABRIC_LOGGING_SPEC=DEBUG
Or else,
try setting up in you cli for one time use
export
I've installed the latest RabbitMQ server (rabbitmq-server-3.3.0-1.noarch.rpm) on a fresh Centos 5.10 VM according to the instructions on the official site.
I've done this many times before during development and never had any issues. However, this time I cannot log into the management web interface using the default guest/guest user.
In the logs, I see the following:
=ERROR REPORT==== 4-Apr-2014::00:55:15 ===
webmachine error: path="api/whoami"
"Unauthorized"
What could be causing this?
It's new features since the version 3.3.0
http://www.rabbitmq.com/release-notes/README-3.3.0.txt
server
------
...
25603 prevent access using the default guest/guest credentials except via
localhost.
If you want enable the guest user read this or this RabbitMQ 3.3.1 can not login with guest/guest
# remove guest from loopback_users in rabbitmq.config like this
[{rabbit, [{loopback_users, []}]}].
# It is danger for default user and default password for remote access
# better to change password
rabbitmqctl change_password guest NEWPASSWORD
If you want create a new user with admin grants:
rabbitmqctl add_user test test
rabbitmqctl set_user_tags test administrator
rabbitmqctl set_permissions -p / test ".*" ".*" ".*"
Now you can access using test test.
If you still can't access the management console after a fresh install, check if the management console was enabled. To enable it:
Go to the RabbitMQ command prompt.
Type:
rabbitmq-plugins enable rabbitmq_management
Something that just happened to me and caused me some headaches:
I have set up a new Linux RabbitMQ server and used a shell script to set up my own custom users (not guest!).
The script had several of those "code" blocks:
rabbitmqctl add_user test test
rabbitmqctl set_user_tags test administrator
rabbitmqctl set_permissions -p / test ".*" ".*" ".*"
Very similar to the one in Gabriele's answer, so I take his code and don't need to redact passwords.
Still I was not able to log in in the management console. Then I noticed that I had created the setup script in Windows (CR+LF line ending) and converted the file to Linux (LF only), then reran the setup script on my Linux server.
... and was still not able to log in, because it took another 15 minutes until I realized that calling add_user over and over again would not fix the broken passwords (which probably ended with a CR character). I had to call change_password for every user to fix my earlier mistake:
rabbitmqctl change_password test test
(Another solution would have been to delete all users and then call the script again)
If on Windows and installed using chocolatey make sure firewall is allowing the default ports for it:
netsh advfirewall firewall add rule name="RabbitMQ Management" dir=in action=allow protocol=TCP localport=15672
netsh advfirewall firewall add rule name="RabbitMQ" dir=in action=allow protocol=TCP localport=5672
for the remote access.
I also couldn't log in to Rabbit's web interface. in my case, cookies were disabled in the browser for this web interface. I allowed cookies to be saved and rebooted chrome. and I was able to log in again.
If you are in Mac OS, you need to open the /usr/local/etc/rabbitmq/rabbitmq-env.conf and
set NODE_IP_ADDRESS=, it used to be 127.0.0.1. Then add another user as the accepted answer suggested.
After that, restart rabbitMQ, brew services restart rabbitmq
I have a Tomcat installation where I suspect the thread pool may be decreasing over time due to threads not being properly released. I get an error in catalina.out when maxthreads is reached, but I would like to log the number of threads in use to a file every five minutes so I can verify this hypothesis. Would anyone please be able to advise how this can be be done?
Also in this installation there is no Tomcat manager, it appears whoever did the original installation deleted the manager webapp for some reason. I'm not sure if manager would be able to do the above or if I can reinstall it without damaging the existing installation? All I really want to do is keep track of the thread pool.
Also, I noticed that maxthreads for Tomcat is 200, but the max number of concurrent connections for Apache is lower (Apache is using mod_proxy and mod_proxy_ajp (AJP 1.3) to feed Tomcat). That seems wrong too, what is the correct relationship between these numbers?
Any help much appreciated :D
Update: Just a quick update to say the direct JMX access worked. However I also had to set Dcom.sun.management.jmxremote.host. I set it to localhost and it worked, however without it no dice. If anyone else has a similar problem trying to enable JMX I recommend you set this value also, even if you are connecting from the local machine. Seems it is required with some versions of Tomcat.
Just a quick update to say the direct JMX access worked. However I also had to set Dcom.sun.management.jmxremote.host. I set it to localhost and it worked, however without it no dice. If anyone else has a similar problem trying to enable JMX I recommend you set this value also, even if you are connecting from the local machine. Seems it is required with some versions of Tomcat.
Direct JMX access
Try adding this to catalina.sh/bat:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=5005
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
UPDATE: Alex P suggest that the following settings might also be required in some situations:
-Dcom.sun.management.jmxremote.host=localhost
This enables remote anonymous JMX connections on port 5005. You may also consider JVisualVM which is much more please and allows to browse JMX via plugin.
What you are looking for is Catalina -> ThreadPool -> http-bio-8080 -> various interesting metrics.
JMX proxy servlet
Easier method might be to use Tomcat's JMX proxy servlet under: http://localhost:8080/manager/jmxproxy. For instance try this query:
$ curl --user tomcat:tomcat http://localhost:8080/manager/jmxproxy?qry=Catalina:name=%22http-bio-8080%22,type=ThreadPool
A little bit of grepping and scripting and you can easily and remotely monitor your application. Note that tomcat:tomcat is the username/password of user having manager-jmx role in conf/tomcat-users.xml.
You can deploy jolokia.war and then retrieve mbeans values in JSON (without the manager):
http://localhost:8080/jolokia/read/Catalina:name=*,type=ThreadPool?ignoreErrors=true
If you want only some values (currentThreadsBusy, maxThreads, currentThreadCount, connectionCount):
http://localhost:8080/jolokia/read/Catalina:name=*,type=ThreadPool/currentThreadsBusy,maxThreads,currentThreadCount,connectionCount?ignoreErrors=true
{
request: {
mbean: "Catalina:name="http-nio-8080",type=ThreadPool",
attribute: [
"currentThreadsBusy",
"maxThreads",
"currentThreadCount",
"connectionCount"
],
type: "read"
},
value: {
currentThreadsBusy: 1,
connectionCount: 4,
currentThreadCount: 10,
maxThreads: 200
},
timestamp: 1490396960,
status: 200
}
Note: This example works on Tomcat7 +.
For a more enterprise solution. I have been using New Relic in our production environment.
This provides a graph of the changes to the threadpool over time.
There are cheaper tools out meanwhile: I am using this jar here: https://docs.cyclopsgroup.org/jmxterm
You can automate it via shell/batch scripts. I regexed the output and let prometheus poll it for displaying it in grafana.
We are tracking down some memory issues in our application and we have visibility into the size of our sessions where the problem seems to be. It is only affecting certain sessions where they seem to balloon out of control and we'd like to have the ability to invalidate those sessions more-or-less 'by hand' to reclaim that memory . Is there a way to do this through JMX? We are using JBoss 4.5.2 .
Thanks in advance.
The answer is yes, you can.
--this gets the web module MBeans loaded in JBoss--
/opt/lib/jboss-4.2.3.GA/bin/twiddle.sh -s <--ServerIP-->:1099 query 'jboss.web:*' | grep "type=Manager"
--Once you have that you can get the active sessions from that MBean--
/opt/lib/jboss-4.2.3.GA/bin/twiddle.sh -s 172.16.0.216:1099 invoke "<--MBean-->" listSessionIds
--And finally, once you have that list, you can pick out the session of interest and expire it--
/opt/lib/jboss-4.2.3.GA/bin/twiddle.sh -s <--ServerIP-->:1099 invoke "<--MBean-->" expireSession <--SessionID-->
You would replace <--ServerIP--> with the ip the server is bound on...it need not be local. This can be run remotely as long as you have access to port 1099.
<--MBean--> would be replaced with one of the results of the first query.
<--SessionID--> would be replaced with one of the session ids from the second command.
Also you would replace /opt/lib/jboss-4.2.3.GA/bin/twiddle.sh with the location of twiddle on your machine. It is included in JBoss.
Thanks Ichorus. Your solution helped me with at least some way to see all the active sessions on the server at any given time.
Btw...Here are couple of things needed before running twiddle.sh
Make sure JAVA_HOME and JBOSS_HOME are set in the environment
And Make Sure JBOSS_CLASSPATH is either not set or has all the libs given in twiddle.sh.i.e {JBOSS_HOME}\client\jbossall-client.jar;{JBOSS_HOME}\client\getopt.jar;{JBOSS_HOME}\client\log4j.jar; {JBOSS_HOME}\lib\jboss-jmx.jar
Other wise you would run into ClassNotFound exceptions
Sudheer