I have written a cron to run every 30 minutes in scheduled-action-services-context.xml file
However I see that it is not working, when I check the log I can find only this error.
For my cron, I have also used lucene search. So I beleive this error is regarding that, so kindly help me in fixing it. Here is the error:
ERROR [quartz.core.JobRunShell] [DefaultScheduler_Worker-8] Job jobGroup.jobD threw an unhandled Exception:
org.alfresco.repo.search.impl.lucene.LuceneQueryParserException: 03020086
The error log you show is most likely the reason behind your scheduled action not properly working. In facts, it seems that the action is properly scheduled, but it then fails to complete as you provided an invalid Lucene query. Without the query itself or any other detail such as the relevant Spring config or action implementation details, I can only tell you to:
double check the lucene query
verify that that error log appears precisely when you would expect your action to be scheduled
Related
I suppose that this is more of a curiosity as opposed to an actual issue, but I thought I'd ask about it anyway. There are times when an uncaught error occurs in a server-side NetSuite script using SuiteScript 2.0/2.1 (2.x), but instead of seeing a "SYSTEM" scripting log entry, there's nothing. It gives the appearance of a script just stopping for no reason. Now, I know this can easily be avoided by wrapping everything within a try-catch block, but that's not what I'm trying to discuss here.
Does anyone have any insight into why a script would just stop without any SYSTEM error logging? It's just something I find interesting given that with the 1.0 API uncaught errors would always get logged. And it's not a guarantee that an uncaught error won't be logged as a SYSTEM log. It seems more common with map/reduce scripts, but unless memory is not serving correctly I believe that I have seen it happen with suitelets and user event scripts, too.
Just thought that I'd pose the question here to see if there was anyone who might know a little something about it.
This is actually covered in the system help for Map/Reduce scripts. They do fail silently. I've not seen this in any other script type.
I am new to BigQuery and trying to schedule a query. However, I am getting "Scheduled Query Error", although settings are valid. The query also runs manually without problems.
The IAM permissions are set up to bigquery.admin. Any ideas what could be the reason for this error message?
I also tried running the query before setting up the schedule, as recommened on one forum. But still got the same error message.
I have a fully developed set of functions which work fine in the "dev" stage and it's now time for me deploy to production. Unfortunately every time I try to deploy it goes for a long time but after printing "Checking Stack update progress" it fails with a 404 error:
An error occurred: SentinelLambdaFunction - Function not found: arn:aws:lambda:us-east-1:837955377040:function:xyz-services-prod-sentinel (Service: AWSLambda; Status Code: 404; Error Code: ResourceNotFoundException; Request ID: 38f86b7a-99cd-11e8-af06-fffd92e40dc5).
This error is non-sensical to me as this function does exist and executing precisely the same full deployment to "dev" results in no error. Note that in both environment/stage, we are deploying 10 functions with a fully deployment.
I tried removing the function which was being complained about first, with the hope that I could re-include it on a second deployment but then it simply complained about a different function not existing.
I also thought maybe the "--force" parameter might push this deployment into place but it has had no impact on the error I get.
The cycle time for each attempt is very long so I'd be very grateful if anyone could help to point me in the right direction on this.
Below is a screenshot of the output when run in "verbose" mode:
In attempt to get around the error I thought maybe I'd have a better chance if I went into CloudFormation and explicitly deleted the template for prod. I attempted to do this from the GUI and got the following:
This actually has further convinced me that this removal is important but I'm not sure what to do next.
For me, the solution was:
serverless remove
and then try deploying again.
So the solution to this problem was to ensure that all previous traces of the CloudFront stack was removed. In my case I had manually taken out a few functions from Lambda and the 401 errors I was getting were likely occuring in the removal attempts rather than my assumption that it was related to adding these functions.
Bear in mind you may find yourself -- like I did -- where the first attempt to delete fails. In this case try again and make sure to check off any checkboxes exposed by UI that indicate what had caused the issues the prior attempt.
Once I'd done that I was able to deploy as per normal from the serverless framework.
I am having difficulty getting a BigQuery job to execute from the Web Interface. If I try to run the job I get the error message
Error: An internal error occurred and the request could not be completed.
Job ID: rhi-localytics-db:job_V-6F5YOk0k9ENTgDfGX84Ghnxz8
Does anyone have any idea what problem this error message means? The query I'm using is not terribly complicated.
Thanks,
Brad
I checked the internal error details and your query appears to have hit a transient internal error. The error should have nothing to do with your specific query. We'll investigate internally to reduce the occurrence of errors like this.
Does your query reliably fail with this error if you rerun it, or did you only receive this error on the one query job?
Thank you for the report. We are now tracking the issue internally.
I guess by default only error with severity 20-25 will gets logged into SQL Server error log file. How can I change the config to log even other errors which are less severity? Or where I can find less severe errors getting logged in SQL Server? I am interested in errors such as
could not find stored procedure spName
etc.
I extracted the following block from this article, which would be a good starting point to explore the SQL Server error log config changes.
Logging Errors
SQL Server Agent takes these errors from the error log, so if follows that the errors must be logged in the first place. There is no way of attaching alerts to errors that aren't logged. All error messages with a severity level from 19 through 25 are written to the error log automatically.
So, what if you want to log information messages, or messages of low severity? If you wish to have an alert on any errors that are of a severity less that 19, then you have to modify their entry in the sysmessages table to set them to be always logged.
You do this using sp_alterMessage with the WITH_LOG option to set the dLevel column to 128 . If a message has been altered to be WITH_LOG, it is always subsequently written to the application log, however the error happens.
Even if RAISERROR is executed without the WITH LOG option, the error that you have altered is written to the application log, and is therefore spotted by the alert. There are good reasons for wanting to do this, as it will then log, and optionally alert you to, syntax errors that are normally seen only by the end-user.
You can force any error that is triggered programmatically to be written to the error log by using the WITH LOG parameter with the RAISERROR command. So, with a user-defined error severity (9) you can log an incident, cause an alert to be fired, which in turn emails someone, or runs a job, simply by using RAISERROR.
Naturally, because the job that responds to the alert can be run by the Agent under a different User, you do not need to assign unsafe permissions to the ordinary user. You can use xp_LogEvent if, as is likely, you do not want the user to see the error. (Only the Raiserror call can utilize the 'PrintF' formatting placeholders in the error messages, so logging the error with a formatted message using xp_logevent results in a literal recording of the message, string format identifiers and all.)
I would recommend to refer the original article for more/detailed information on this.
Please follow this link to find out more on severities.