Error Description:
The BAR File contains .msgflow files and this broker does not support them. To deploy this BAR file to the target broker save the BAR file selecting the 'Compile and in-line resources option'.
Check that,
1. The broker is running.
2. The TCP/IP port of the queue manager is active if it is remote.
Details Error Description:
Begin running task [Deploying [RecordAndReplyExample] to execution group [default]]
The deployment was unsuccessful due to unknown reason.
The task was unsuccessful: The deployment was unsuccessful due to unknown reason.
Did anyone know how to solve this?
It would appear that you are trying to use features in the message flow that are not supported by the broker you are attempting to deploy it to.
From that error message, and with no version info provided by the OP, I would guess that you are trying to use a BAR file that contains .msgflow files on a broker that only supports compiled flows in .cmf files. If this is the case then you will need to either use a later version of MB/IIB that supports this feature, 8 FP1 or later, or recreate your BAR file with the 'Compile and in-line resources option' option set in the toolkit on the save BAR file screen.
Related
I wrote microservices using spring boot. some time showing its active in status and sometimes showing inactive, I can't understand the behaviour of microservice and how can debug it
Have you tested running the microservice locally?
I've been getting inconsistent reports from the status tab in the UI. Sometimes it says the service is down when it's actually up. I check the /health endpoint to be sure(it's not available right after you upload the zip, takes 5-6 minutes).
The logs in the UI are a bit clunky, so I've added a rolling file appender to logback.xml and a rest endpoint to expose the log file for debugging.
Try to override health check timeout value (timeoutSeconds property of Probe). By default it's 1 second and it's often not enough. Please refer our specification: https://cumulocity.com/guides/reference/microservice-manifest/
In the administration application you will find the status details for each of your applications.
When the status is switching all the time probably the docker container is terminating all the time (probably because the application is crashing). You should the that on the status tab of the application in the event log (container is restarted all the time).
If you are on the newest Cumulocity version (9.19.x) you should also have access to the logs of the microservice at the same place in UI. You need to log to stdout in order to be able to get the logs through administration application.
The system environment check returned errors. Those errors will affect the functionality and stability of your TYPO3 CMS instance. Please check the install tool "System environment" for all details.
The first image shows the typo3 backend status report error:
Here is the error on browser when I tried to access the frontend of the website:
About the exception you are getting: It seems you stumbled upon a bug which is fixed in latest version 7.6.26. Please update to the latest version. Make sure you follow the correct procedure for updating.
If the problem still occurs, clear the system cache in the install tool.
More general hints:
Always keep your TYPO3 system up to date. Either subscribe to the typo3-announce mailing list or keep track of the channel #announcements in the typo3 slack workspace. That way you will be notified as soon as a new TYPO3 version is released. If you don't have access to the TYPO3 slack workspace yet, register for an invite.
first:
go to Install-Tool and verify that all checks are green or at least yellow.
then:
if you only got a blank screen your system is probably in production mode where no error messages are shown as they could reveal information for abuse.
So configure developer mode in the Install-Tool.
You also may need to remove the exception handler in your typoscript (setup) with:
config.contentObjectExceptionHandler = 0
to get plain php error messages.
activating developermode :
Install Tool
Configuration Presets
Debug Settings
Debug
Activate settings
I have been working on restoring a build server (tfs 2012) from a backup and all manner of things got messed up (the tfsservice account password had been altered and I had to go to every service and app pool on the box and update it). Once sql was backup I was able to update the password via the TFS admin console app. Then I was able to re-register the build service and add a controller and a build agent. It starts briefly and shows green for a few seconds before stopping and a "details ..." button appears next to the Build Service. If I click the details button I see the following
"Please contact your administrator. There was an error contacting the server. Technical information (for administrator): HTTP code 500: System.ServiceModel.ServiceActivationException"
I have checked the http bindings in iis for the tfs site and there is only the one "*:8080"
I tried hardcoding it to the ip on the box and I still get the same error. If I go to one of the client machines and try and queue a build it shows the build server as being offline.
I have also checked for multiple host headers and the memory utilization which are the most common responses to this particular issue. Neither of them seem to be the cause or the solution.
Any ideas or suggestions are welcome I have run out of ideas to try here. Thanks in advance for any help you have to offer.
EDIT -- also found this in the log: Build machine MyMachine lost connectivity to message queue tfsmq://buildservicehost-25/.
I have a Windows service written in VB.NET 2.0 which connects to an IBM AS/400 server. Queries work fine, but when I try to do something like deleting a spool file, I get errors. For example:
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
Running this command with ExecuteNonQuery yields:
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
However, if I run that same command locally in AS/400, it works just fine. We already checked permissions. What else could be causing the command to fail this way? How can I get more information about the error, or go about troubleshooting this?
EDIT: This problem (and a lot of other ones) appeared when we migrated our server (where the .NET service runs) from Windows Server 2003 to Windows Server 2008.
How can I get more information about the error, or go about troubleshooting this?
The first thing is to verify that the IBM AS/400 server [what OS Version Release and Modification level, Technical Refresh (TR) level (if instead IBM i), Cumulative PTF level were all omitted.?.?] used for the connection is the same server used to perform the command-line invocation; i.e. on the server where the command-line invocation will be made to verify the command is functional, find the active server job in which the CPF3342 is still visible in the log.
The second thing to do is to get the spooled joblog showing the full details of the CPF3342 [and possibly any preceding message(s) that might be related]. If for example the message is not actually that message or is not sent by the expected program QSPCPYF, then immediately the direction of investigation probably would change. What is shown is apparently what is presented at the client, not what came from the server joblog; the USEnglish formatting I believe is "Job &5/&4/&3 not found." for which the formatting "CPF3342 - Job not found &5/&4/&3" is suspect.
To ensure the most appropriate comparison to the request made from the client:
• the local user that is signed-on to perform the same request should be the same user as the Current User of the active job found to be servicing the client request
• the local user should establish the same System Library List as the active job found to be servicing the client request
If such an incident recurs or even if the same incident persists, then verify the once again the re-create is still possible using the same interface [i.e. the condition\failure persists] and again verify the command-line request is successful [i.e. the circumvention is confirmed, that the same request is possible to be performed at the command-line]; and according to my earlier comment, first ensuring the same server by finding the active job that logs the CPF3342. Immediately afterward:
• Collect a job trace for the Copy Spooled File (CPYSPLF) request; for the failing case, review for any exception\interrupt conditions [with or without a message as accompanying trace data] that precede the program flow for the issuance of the msg CPF3342.
• Review the audit log for any T-AF or anything odd\unexpected at very close to the time of the failing request; expansive auditing should have been established since before the connection to the server.
• Contrast those data collections of the failing case with the same data taken from the successful processing.
Although the symptom [as lightly described, without the full joblog] the possibility of command-exits seems remote, the trace would reveal if the command in either scenario were intercepted by the Command Exit points; these can be reviewed separately [rather than looking in the trace] for any Exit Program, using the Work With Registration Information (WRKREGINF) to review any QIBM_QCA* entries in the repository for what exit programs might impact the CL Command request. But IIRC the trace-data shows which command was invoked, so the trace would also reveal if the unqualified command requests resolved to different *CMD objects.
For one of our gerrit projects, while navigating the file differences we get this error:
Application Error
Intraline difference not available due to server error
[Continue]
It doesn't happen for all projects, currently we've detected the error on only one project.
I looked on Google and on the gerrit documentation. Found a reference on their source code, but don't know what causes it and how it can be resolved.
The web page with the error contains a "Continue" button. Once clicked it will take you to the file you selected, but the error is annoying.
Do you know how to fix this?
That is caused while cache the intraline difference of one file, when compared between two commits. The default timeout value is 5 seconds. If the file is huge, and computation takes longer than the timeout, the worker thread is terminated, an error message is shown, and no intraline difference is displayed for the file pair.
A solution could fix this.
Add config in gerrit.conf.
[cache "diff_intraline"]
timeout = 15000 ms # Or other time length as you want.
restart Gerrit service
run SSH command "gerrit flush-caches", using a user with ViewCaches global capability.
ssh -p port userxxx#host gerrit flush-caches
Then it would work.
Cause of the error:
It is a result of Gerrit taking too long to diff the file, and marking the diff in one of its caches as non-available.
The relevant error log is here:
[2012-06-08 11:14:08,547] WARN com.google.gerrit.server.patch.IntraLineLoader : 5000 ms timeout reached for IntraLineDiff in project xxxxxxx on commit 354dd67ad54578cf801d8cda64a4ae8484ebb0b7 for path xxxxxxx.java comparing bf9fbc21520af7bfd0841c8b9f955ca6e215b059..f6b9c7992c12cfdca253acd033966f98f70f3543. Killing IntraLineDiff-6