I am using a tried version of botium. The solution which was provided previously for such an issue was to check the heartbeat of botium agent.
Here is a screenshot:
I am able to connect to the kori.ai chatbot and then connect the test set but on running, I get the error:
Job queued for execution
and on doing the live chat with the bot, I get the error:
504 gateway timeout
Related
Os:Windows
Machines:vdi, remote machines
Getting connection timeout error in jmeter distribution testing while clicking remote start all but scripts r working fine normally
If you're getting connection timeouts between JMeter master and slaves - check your JMeter instances RMI configuration
JMeter master should be able to connect to the slaves to transfer the .jmx script to them
JMeter slaves should be able to connect to the master to transfer the test results back
If you're getting connection timeouts as the result of your Samplers it might be the case that your application under test gets overloaded because if you have 100 user in Test Plan and 1 slave - it will kick off 100 users, each additional slave will add 100 more users so if you have 10 slaves it will be 1000 users. Check Active Threads Over Time Listener (can be installed using JMeter Plugins Manager) to see what is perceived load you generate
Invest into learning some English or if you know it better than me consider changing the way you're asking for help b'cause u r not # Tinder. How do I ask a good question? is a very good place to start.
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.
We are experiencing problems with the notifications sent by Orion for new data after the last update to version 2.2.0.
Orion is run inside a Docker container.
Specifically, the problem is this:
when we start the docker container, every endpoint is contacted when a new data arrives. But then, after a while (less than 1 day), some endpoints (currently, the one hosted by Amazon Web Service) stopped to be contacted. The error obtained is: 'notification failure for sender-thread: Timeout was reached'
As additional information,
if we try to send data manually (through a CURL request performed in a bash instance inside the docker container) it works fine. While Orion cannot contact the endpoint falling in a "Timeout" exception.
Furthermore, if we restart the container (with consequent deletion of the contextBroker.pid from the dedicated folder in (/var/lib/docker/overlay2/)), it starts to push data again.
Linked issue on github
I am setting up splunk to monitor continuum and its logs, which log files of continuum would be important to monitor?
Logs in VersionOne Continuum can be thought of in two categories - service logs and automation logs.
Service logs will give you insights into warnings and errors with the UI, API and other core processes. Specifically watch for CRITICAL and ERROR in the messages.
Automation logs are more targeted to the teams use of the value stream orchestration. Still, it would be useful to monitor the logs in /pi and /te for CRITICAL and ERROR, as well as the keyword failure in /pi and the keyword Error in /te, as these indicate automation routines that have completed successfully but where their goals have failed.
From time to time, all systems experience problems sending email messages. Monitoring the ctm-core log will reveal to you when the system is unable to send a notification after the max retries.
I'm a fairly new user of ActiveMQ and I'm looking for a way to get detailed debug information on the client side of a queue connection. My problem is this: I have a server that is sending a message through a queue to a client. Using the admin web page associated with the broker, I can verify the following: the queue was created, there is a consumer associated with the queue, the message has been enqueued, the message has been dispatched, the dispatched queue size is 1, the message has not been dequeued. This setup was working yesterday but mysteriously stopped working today even though I did a restart of the activemq service. The log file at /var/log/activemq.log does not contain any useful information.
At this point I'm stumped; I'm assuming that there is some sort of problem with the configuration, but it hasn't changed since yesterday. Does anybody have a suggestion about what my next step should be?
Turn on debug (or even trace) logging in the broker first of all in conf/log4j.properties.
log4j.logger.org.apache.activemq=DEBUG
restart the broker and re-run your scenario. The logging will hopefully provide you with some information.
Jconsole is also a useful tool to monitor the running broker.
Does your client use any message filters?
You can also enable remote debugging and then connect with an IDE.
To start remote debugging execute
$ ACTIVEMQ_DEBUG=true bin/activemq
and then start a remote debugger to connect to port 5005