misfire视频,misfire中文是什么意思

misfire，最近不少朋友在找misfire中文是什么意思的相关介绍，兔宝宝游戏网给大家详细的介绍一下，希望对大家有帮助。

1、misfire视频：

故障码:P0300 中文定义:随机/多个气缸检测到失火 英文定义:Random/Multiple Cylinder Misfire Detected 范畴:点火系统 背景知识:气缸失火是指发动机工作过程中由于各种原因造成的混合气在气缸内不能正常燃烧的现象。如果电子控制单元（ECU）检测到可能会对催化转换器造成破坏的失火，故障指示灯会闪烁，此时应立即关闭发动机。该故障码表明有多个气缸失火或者是电子控制单元（ECU）不能确定哪一个气缸失火。故障原因包括气缸机械故障，燃油计量错误，燃油压力太高或太低，蒸发排放系统故障，EGR阀卡在开，PCV系统真空泄漏，点火系统故障，空气流量计故障，油箱内燃油液位过低。

2、quartz的misfire机制：

转自 https://dzone.com/articles/quartz-scheduler-misfire

如果在程序日志中遇到"Misfire trigger DEFAULT.TASK_5da1331f483c1a282437e3b5."异常(可能伴随"Skipping trigger DEFAULT.TASK_5da1331f483c1a282437e3b5 as it misfired and was scheduled for 2022-06-27T09:14:00.000+0800."),那么本文绝对能清楚解答你的疑惑.

本文按照任务执行一次,执行多次,无限执行和cron执行4种trigger来讲解misfire策略.

Sometimes Quartz is not capable of running your job at the time when you desired. There are three reasons for that:

You can increase the number of worker threads by simply customizing the org.quartz.threadPool.threadCount in quartz.properties (default is 10). But you cannot really do anything when the whole application/server/scheduler was down. The situation when Quartz was incapable of firing given trigger is called misfire . Do you know what Quartz is doing when it happens? Turns out there are various strategies (called misfire instructions ) Quartz can take and also there are some defaults if you haven't thought about it. But in order to make your application robust and predictable (especially under heavy load or maintenance) you should really make sure your triggers and jobs are configured conciously.

There are different configuration options (available misfire instructions ) depending on the trigger chosen. Also Quartz behaves differently depending on trigger setup (so called smart policy ). Although the misfire instructions are described in the documentation, I found it hard to understand what do they really mean. So I created this small summary article.

Before I dive into the details, there is yet another configuration option that should be described. It is org.quartz.jobStore.misfireThreshold (in milliseconds), defaulting to 60000 (a minute). It defines how late the trigger should be to be considered misfired . With default setup if trigger was suppose to be fired 30 seconds ago, Quartz will happily just run it. Such delay is not considered misfiring. However if the trigger is discovered 61 seconds after the scheduled time - the special misfire handler thread takes care of it, obeying the misfire instruction. For test purposes we will set this parameter to 1000 (1 second) so that we can test misfiring quickly.

In our first example we will see how misfiring is handled by simple triggers scheduled to run only once:

The same trigger but with explicitly set misfire instruction handler:

For the purpose of testing I am simply scheduling the trigger to run 10 seconds ago (so it is 10 seconds late by the time it is created!) In real world you would normally never schedule triggers like that. Instead imagine the trigger was set correctly but by the time it was scheduled the scheduler was down or didn't have any free worker threads. Nevertheless, how will Quartz handle this extraordinary situation? In the first code snippet above no misfire handling instruction is set (so called smart policy is used in that case). The second code snippet explicitly defines what kind of behaviour do we expect when misfiring occurs. See the table:

This scenario is much more complicated. Imagine we have scheduled some job to repeat fixed number of times:

In this example the trigger is suppose to fire 8 times (first execution + 7 repetitions) every hour, beginning at 9 AM today (startAt(dateOf(9, 0, 0)). Thus the last execution should occur at 4 PM. However assume that due to some reason the scheduler was not capable of running jobs at 9 and 10 AM and it discovered that fact at 10:15 AM, i.e. 2 firings misfired. How will the scheduler behave in this situation?

In this scenario trigger repeats infinite number of times at a given interval:

Once again trigger should fire on every hour, beginning at 9 AM today (startAt(dateOf(9, 0, 0)). However the scheduler was not capable of running jobs at 9 and 10 AM and it discovered that fact at 10:15 AM, i.e. 2 firings misfired. This is a more general situation compared to simple trigger running fixed number of times.

CRON triggers are the most popular ones amongst Quartz users. However there are also two other available triggers: DailyTimeIntervalTrigger (e.g. fire every 25 minutes ) and CalendarIntervalTrigger (e.g. fire every 5 months ). They support triggering policies not possible in both CRON and simple triggers. However they understand the same misfire handling instructions as CRON trigger.

In this example the trigger should fire every hour between 9 AM and 5 PM, from Monday to Friday. But once again first two invocations were missed (so the trigger misfired) and this situation was discovered at 10:15 AM. Note that available misfire instructions are different compared to simple triggers:

QTZ-283 Note : QTZ-283: MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY not working with JDBCJobStore - apparently there is a bug when JDBCJobStore is used, keep an eye on that issue.

As you can see various triggers behave differently based on the actual setup. Moreover, even though the so called smart policy is provided, often the decision is based on business requirements. Essentially there are three major strategies: ignore , run immediately and continue and discard and wait for next . They all have different use-cases:

Use ignore policies when you want to make sure all scheduled executions were triggered, even if it means multiple misfired triggers will fire. Think about a job that generates report every hour based on orders placed during that last hour. If the server was down for 8 hours, you still want to have that reports generated, as soon as you can. In this case the ignore policies will simply run all triggers scheduled during that 8 hour as fast as scheduler can. They will be several hours late, but will eventually be executed.

Use now * policies when there are jobs executing periodically and upon misfire situation they should run as soon as possible, but only once. Think of a job that cleans /tmp directory every minute. If the scheduler was busy for 20 minutes and finally can run this job, you don't want to run in 20 times! One is enough, but make sure it runs as fast it can. Then back to your normal one-minute intervals.

Finally next * policies are good when you want to make sure your job runs at particular points in time. For example you need to fetch stock prices quarter past every hour. They change rapidly so if your job misfired and it is already 20 minutes past full hour, don't bother. You missed the correct time by 5 minutes and now you don't really care. It is better to have a gap rather than an inaccurate value. In this case Quartz will skip all misfired executions and simply wait for the next one.

总结：以上内容就是针对misfire视频,misfire中文是什么意思的详细介绍，大家可以参考一下。