I'm attempting to use OpsCenter 6.1 to install a new cluster. OpsCenter successfully ssh's to each of the nodes in the cluster then appears to nearly immediately error out on each node with the following message:
400 Client Error: Bad Request for url: http://<opscenter>:8888/api/v1/lcm/internal/nodes/<node-id>/package_information
When attempting to reach that page myself I receive a 404 error with this message:
{"brief": "error", "message": "{\"type\":\"ApiException\",\"code\":404,\"msg\":\"Can't find object for given parameters: {:job-id nil, :node-id \\\"<node-id>\\\"}\"}", "type": "NoSuchResource"}
Note that <opscenter> (above) is the IP address of my local install, and <node-id> is the ID of the node.
Considering that I don't receive the 400 error myself I'm assuming that I'm unable to replicate the scenario that occurs during the install because of some perviously executed steps that are rolled back.
Any insight into what might be causing this issue?
Thanks in advance!
LCM developer here... It's hard to know exactly what's wrong based on the information provided. But here are some tips:
If there's an api error during a job, the error will be recorded in opscenterd.log (usually in /var/log/opscenter in package installs, or in something like ./log/ in tarball installs).
The internal api is private and is not publicly documented. It's authenticated via a per-node secret token that's only valid during the lifetime of a job, so it's fairly challenging to try to ping internal urls manually, we've never needed to have someone try to ping internal api's to successfully diagnose issues in the past. It's not something I'd recommend spending a lot of time on.
You might get more context about LCM is doing when the error happens by turning the "lcm" logger up to debug in opscenter's logback.xml and restarting opscenterd.
Related
We are attempting to deploy a SignalR site on a Citrix NetScaler, as opposed to the current deployment on a single server. There are three servers in the farm. If you navigate to any single server, SignalR comes up fine. If you go to the NetScaler address, you get this:
WebSocket connection to
'wss://mysite.com/myapp/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=(token_displayed_here)'
failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET
After this error, there is about a 10-15 second delay, then it starts working. If I attempt to disable websockets as I have read that Netscalers still have issues with them, the error goes away but the delay remains. I believe the delay is caused by it trying to connect with ServerSentEvents and failing that as well. It appears that only long polling may be working over the NetScaler.
We have checked the NetScaler websocket settings, made sure the servers have the correct machine keys, had a backplane set up (tried Redis and an Oracle Nuget package as that's our typical DB), checked the OWIN versions and web.config settings, all of the stuff that Google told me to do that I could find but still get this error and delay. One thing that I did find is that Netscalers have issues with wss, but haven't been able to find anything about how to account for this. Most of the information found was for people using other load balancing technology.
Is using SignalR (or more specifically, WebSockets or ServerSentEvents) with a NetScaler even doable, and if so what could be causing this problem?
I am facing a problem with logging into TFS. I get the following error:
Exception Message: TF246017: Team Foundation Server could not connect
to the database. Verify that the server that is hosting the database
is operational, and that network problems are not blocking
communication with the server. (type SoapException)SoapException
Details:
Hi the below steps worked for me.
Select Application Tier in the TFS Administration Console.
In the Application Tier Summary which contains the Service Account details.
Click Reapply Account.
I know this is old, but here was my situation:
We have 11 collections on our instance, 2 were failing with this error, showing me it wasn't an access / connection issue. Checking Event Viewer (as #Andy Li-MSFT suggests) showed it was
A timeout occurred while waiting for memory resources to execute the query in resource pool 'default' (2). Rerun the query.
Checking task manager showed the culprit - elastic search was using well over 2GB of memory. I killed the service, the collections applied the patch quickly without issue.
Looks like I need to ask our server admins to give us a bit more memory....
Please check below thing to narrow down the issue:
Make sure you are the member of the Administration Console Users.
Otherwise you cannot access the Admin Console.
Make sure the SQL Server is stated and available, and the network
connectivity is OK.
Check the Service Account, make sure the Service Account has been added in
SQL Server.
You can also refer to the solution in below link to fix the issue:
https://www.ganshani.com/alm/tfs/visual%20studio/solved-tf246017-team-foundation-server-could-not-connect-to-the-database/
If above solution can not resolve the problem, please check the Event log. The Windows Event Log is a good candidate where to look for the potential cause.
For me I've solved the issue by changing the recovery mode Simple -> Full in the database.
Please refer to: https://www.mssqltips.com/sqlservertutorial/3/sql-server-full-recovery-model/
I configured a message processor in ESB WSO2. every now and then, all the messages are not carried out and they stay pending in the queue (message broker)
I can I can find only this log in the ESB console
"BlockingMessageSender of message processor [SAPMoveMaterialMessageProcessor] failed to send message to the endpoint"
My questions:
1, how and where can I see the real reason (detailed logs, error msg) why the message processor could not be sent out? I have defined a Fault sequence on the message processor but shows nothing
2, in case that I get this issue in the production environment is there a way how to "copy" a pending message (from the message broker queue) to my DEV environment and debug it there?
thank you very much for your ideas!
AFAIK you can get more details from enabling DEBUG logs related to message processors. You can get these in the server management console tools- >'logging' and doing a search for matches which contains 'messageprocessor' and make the log level to DEBUG.
eg:
org.wso2.carbon.message.processor.service.MessageProcessorAdminService
org.wso2.carbon.message.processor.MessageProcessorServiceComponent
As a solution for this you can try out by using a clone mediator (the use of clone mediator here is to make multiple identical copies of the message) inside the fault sequence (when pending message gets fail to consume) to persist to a database - may be to your dev environment.
We have two jira installations at our company. One that we use for our projects and a second one for testing purposes.
I'm working in a project that needs to use the JIRA REST API. For this purpose I'm connecting to our testing instance.
The problem is that while trying out the REST API, I keep getting 400 errors without a single explanation of what went wrong. I just get an HTML with
Your browser sent a request that this server could not understand
I was a bit desperate and decided to try it into our real JIRA. To my surpirse the same request gave me a different response:
{"errorMessages":[],"errors":{"project":"project is required"}}
In this case, I do get a meaningful error!
I replicated this easily. I would never get a meaningful error from the test instance, but the real one will always give me one.
I cannot keep trying out stuff in our productive JIRA, but I cannot easily continue working without getting meaningful errors. So, what could be wrong in the testing instance? I could not find any configuration about the 'verbosity' of the API responses.
I believe that this error is returned not by JIRA but rather by proxy web server that is part of you production configuration.
I suggest you to compare HTTP headers that are sent with working requests from your browser with headers you pass via curl. Googling for the "Your browser sent a request that this server could not understand" helps too
I have a web application which i need to be load tested using LoadRunner. When I record the website using vugen it works good and there is no any application bug. But when I tried to replay the script, script failed after login and while navigating to next page, say, Transaction. At the end of log, I receive error:
Action.c(252): Error -26612: HTTP Status-Code=500 (Internal Server Error)
for "http://rob.com/common/transaction
Please help me to resolve this error.
LoadRunner generates HTTP request just as your browser does, this error is the same error you would get if you would go to that URL using your browser. Error code 500 is a generic server error that is returned when there is no better (more specific error to return).
Most likely the login process requires some form of authentication which is protected against a replay attack by using some form of token. It is up to you to capture this token using Correlations in LoadRunner and replay it as the server expects. The Correlation Studio in VuGen should detect and identify the token for you but since authentication methods vary it is sometimes impossible to do this automatically and you will have to create manual correlation. Please consult the product documentation for more details on how to do it. If your website is publicly available online then post its URL and I will try to record the script on my machine.
Thanks,
Boris.
Most common reasons
You are not checking each request for a valid result being returned and using a 200 HTTP status as an assumed correct step without examining the content of what is being returned. As a result when data being returned is incorrect you are not branching the code to handle the exception. Go one to two steps beyond where your business process has come off the rails with an assumptive success and you will have a 500 status message for an out of context action occurring 100% of the time.
Missed dynamic element. Record three times. Compare the code. Address the changing components.