Service deliver

最新推荐文章于 2020-07-01 17:57:28 发布
最新推荐文章于 2020-07-01 17:57:28 发布
阅读量1.1k 收藏
点赞数
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yww_poison/article/details/83007751
本文介绍了ITIL服务管理中的十大流程及服务台概念，并将其分为服务提供与服务支持两大类。服务提供包括服务等级管理、可用性管理等内容，而服务支持则涵盖服务台、事件管理等流程。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

转载: from http://industry.ccidnet.com/art/1550/20051123/378963_2.html

ITIL包括十大流程和一个服务台，十大流程又可以划分为两大类：一是基于战术层面的服务提供（Service deliver），包括服务等级管理、持续性、可用性、能力和财务管理；二是基于运营层面的服务支持（Service surpport），包括服务台、事件管理、问题管理、配置管理、变更管理、发布管理。

注:

现在的SAP，金蝶，用友之类的都是算做这个Service Delivery的吧

公司刚实施了SAP的HR系统，也是这个萨班斯法案的需求。

以前NI的Olite发布流程，倒也符合文中所说的流程。

yww_poison
关注
Hyperledger Fabric 排序节点处理 Deliver 请求的过程
yeasy的专栏
10-20 3762
Deliver，意味着客户端通过 gRPC 接口从 Ordering 服务获取数据（例如指定区块的数据）。 Orderer 节点收到请求消息，会首先交给 orderer.common.server 包中 server 结构体的 Deliver(srv ab.AtomicBroadcast_DeliverServer) error 方法处理。该方法进一步调用 orderer.common.
sqlserver临时表的删除方法
beautifulsarah的博客
12-28 3509
  if object_id('tempdb..#temp') is not null Begin     drop table #temp End 一个#号的临时表是事务级别的，就是说一个临时表只存在于一个事务里面。一个查询中的代码就是一个事务里面的（不包括拼接的sql语句） CREATE TABLE #temp  (     n
MQ与Webservice的区别
lulu147的专栏
04-20 1万+
Webservice 和MQ(MessageQueue)都是解决跨平台通信的常用手段，两者有哪些区别呢？ 个人认为最本质的区别在于 Webservice近乎实时通信，而MQ却通常是延时通信。 什么意思呢？ 因为webservice其实就是本地服务器程序调用远程服务器上的方法，属于两者之间的交互，请求的时候需要等被请求的服务器做出回应后，另一端才会有所动作，也就是说，如果你请求
fabric 2.0, orderer & peer, Deliver Service
Kingwel Blog
03-17 404
Deliver ServiceDeliver on OrdererHandlerPeerHandlerSame Deliver Handler Both orderer and peer support Deliver service. Deliver on Orderer In AB gRPC server, _AtomicBroadcast_Deliver_Handler supports D...
ITIL与ISO20000的关系
007 James Bond
12-19 1677
摘自豆丁网一篇文章   ITIL它不是一个服务管理标准，而更应该说是一种结构化的方法或流程框架。基于这种方法和框架，已经有越来越多的IT服务管理标准被开发出来了。在这些基于ITIL的IT服务管理标准中，最突出的要属英国标准BS15000-1:2002以及澳大利亚标准AS 8018.1-2004. 此外，还有一个南非版的BS15000标准。国际标准组织（ISO）已经接受了BS1500...
ITIL(v2) 系列学习1
IT新兵
06-22 1359
 前言在2007年ITILv3推出之后，ITIL这个概念从最佳Best practice实践变成最好Good practice实践。从此称呼的转变能够看出ITIL思想的普及化、平民化。ITIL v2已经使用了快20多年了，看看如今的ITIL的用户，成熟度依旧参差不齐。有的已开始琢磨着如何完善所有ITIL Support流程并开展实施ITIL Delivery中的各个流程；有的已经在开始
Hyperledger Fabric从源码分析事件机制（二）
pigff的博客
07-01 1078
上篇文章——Hyperledger Fabric从源码分析事件机制（一），我从 cmd 中添加--waitForEvent参数去监听事件这一入口出发，分析了DeliverClient这一侧的相关源代码，接下来这篇文章将会解析DeliverServer这一侧的相关源代码，准备好上车了兄弟们。 从proto文件中发现DeliverServer 事件相关的pb.go文件在protos/peer/events.pb.go中，关于DeliverServer的部分在576行： // DeliverServer is
BroadcastReceiver最全实例——静态、动态、系统（监听短信、网络连接状态、SD卡、应用安装……）
可乐淘的专栏
04-11 2861
BroadcastReceiver 原理推荐看这篇博客：http://yangguangfu.iteye.com/blog/1063732 实例，请看本文。 AndroidManifest.xml <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.cctvjiata
ClearCase之删除Delivered Baseline的方法
自得其乐的崔秉正
07-18 3741
在ClearCase学习与使用过程中，有时会出现要删除一个Component的问题，但是这时会提示，有Baseline没有删除，仔细检查一下，发现是一些Deliver Baseline，这些Baseline不能直接用cleartool rmbl删除，而IBM Rational ClearCase Support中去搜索，会发现删除这种Baseline的方法只提供给购买了服务的用户，我只好自己尝试。
超级账本Fabric的架构与设计
博客
09-07 6566
超级账本Fabric项目自诞生之日起就吸引了全球众多企业的密切关注，已经先后发布了两个大的版本，0.6实验版本（2016年9月）和1.0正式版本（2017年7月）。 目前，超级账本Fabric架构上核心特性主要包括： 解耦了原子排序环节与其他复杂处理环节，消除了网络处理瓶颈，提高可扩展性； 解耦交易处理节点的逻辑角色为背书节点（Endorser）、确认节点（Committer），可以根据负载...
ClearCase Deliver过程解析
自得其乐的崔秉正
07-12 4746
 本文部分写作于2006年3月，当时主要的目的是明确Deliver步骤，了解如果写针对Deliver写Trigger脚本，最近下载了新的ClearCase 7.0文档，其中有了对Deliver的官方解释，在此做一个对比。我的理解原文：   如果要针对deliver_start这个创建Trigger，则要了解deliver这个clearcase操作具体步骤，以下是我对deliver这个clear
关于Android Service真正的完全详解，你需要知道的一切
热门推荐
zejian的博客
10-07 23万+
Service 1.Service基础知识概述   Service(服务)是一个一种可以在后台执行长时间运行操作而没有用户界面的应用组件。服务可由其他应用组件启动（如Activity），服务一旦被启动将在后台一直运行，即使启动服务的组件（Activity）已销毁了。 此外，组件可以绑定到服务，以与之进行交互，甚至是执行进程间通信 (IPC)。 例如，服务可以处理网络事务、播放音乐，执行文件
Linux 网络启动异常：systemctl status network.service
lzf2284466的博客
05-24 3万+
解决: 查询了一下,好像是系统自带的NetworkManager这个管理套件有关系，关掉. 关掉方法: systemctl stop NetworkManager systemctl disable NetworkManager 重新启动网络： systemctl start network.service 以上失败则继续（MAC地址错误）： ip addr show（查看网卡名） 讲配置文件的hwaddr进行修改 以上失败则继续（网卡、配置文件name、device不一致）..
Fabric 1.0源代码分析(17)gossip（流言算法） #deliverclient（deliver客户端）
尹成的技术博客
05-20 1071
# Fabric 1.0源代码笔记 之 gossip（流言算法） #deliverclient（deliver客户端）## 1、deliverclient概述deliverclient代码分布在gossip/service、core/deliverservice目录下，目录结构如下：* gossip/service目录：    * gossip_service.go，DeliveryService...
scheduleCrash报错：无法传递广播('can't deliver broadcast' failed)如何解决？
最新发布
06-17
<think>我们正在处理一个Android系统报错："scheduleCrashfor'can'tdeliverbroadcast'failed"，具体表现为无法传递广播，导致进程被终止（Crashingit）。根据引用[1]和[2]，该错误通常发生在广播传输过程中，可能由于广播数据量过大或接收进程无法及时处理广播。分析：1.引用[1]显示，BroadcastQueue无法将广播传递给com.baidu.launcher（进程ID为951），因此系统尝试终止该进程。2.引用[2]指出，这可能是由于广播传输的数据量过大，导致抛出RemoteServiceException。同时，该引用还质疑了sendBroadcast方法是否可能抛出RemoteServiceException。解决方案思路：1.检查广播发送的数据量：避免在Intent中传递过大的数据（如位图或大量数据），因为Intent传输有大小限制（通常为1MB左右，不同版本和厂商可能不同）。2.优化广播接收：确保广播接收器（BroadcastReceiver）能够快速处理广播，避免在主线程中进行耗时操作。3.使用其他进程间通信（IPC）方式：如果确实需要传递大量数据，考虑使用ContentProvider、文件共享或基于AIDL的Service等方式。4.检查广播接收器是否被阻塞：如果接收器所在进程的主线程被长时间阻塞，可能导致无法接收广播。确保主线程不被阻塞，耗时操作放在子线程中。具体步骤：步骤1：检查广播发送的数据量-定位发送广播的代码，检查通过Intent传递的数据大小。-如果数据过大，考虑使用其他方式传递，例如只传递一个标识符，然后通过其他方式（如数据库）获取数据。步骤2：优化广播接收器-确保在广播接收器的onReceive()方法中不要进行耗时操作（超过10秒可能导致ANR）。-如果需要执行耗时操作，应该启动一个Service来处理，而不是在接收器中直接处理。步骤3：使用替代的IPC方法-如果数据量很大，使用文件或者ContentProvider共享数据，然后通过广播传递一个指向该数据的URI。步骤4：检查目标进程状态-错误信息显示目标进程（com.baidu.launcher）被终止，可能是因为该进程已经处于不健康状态（如ANR、内存不足等）。需要确保目标进程能够及时处理广播。-如果目标进程是自己的应用，检查是否有内存泄漏、ANR等问题。步骤5：使用显式广播-确保广播是显式的（指定接收者的包名或类名），避免使用隐式广播（除非是系统广播），因为隐式广播在Android8.0（API26）以上被限制。步骤6：增加广播发送的Flags-尝试使用FLAG_RECEIVER_FOREGROUND，使广播优先传递给前台应用。-或者使用FLAG_RECEIVER_REGISTERED_ONLY，只发送给已注册的动态接收器（避免静态接收器延迟）。步骤7：避免在广播中传递自定义Parcelable对象-如果传递自定义Parcelable对象，要求发送端和接收端有完全相同的类（包括包名和类名），否则在反序列化时会出现异常。建议使用基本数据类型或系统支持的Parcelable类型。步骤8：检查系统日志-通过adblogcat获取更多日志，查看是否有相关异常（如TransactionTooLargeException）或其他线索。示例代码优化：假设原始发送广播的代码为：```javaIntentintent=newIntent("com.example.MY_ACTION");intent.putExtra("large_data",largeByteArray);//largeByteArray是一个大字节数组sendBroadcast(intent);```优化为使用文件传递：```java//将大数据写入文件Filefile=newFile(context.getFilesDir(),"temp_data");FileOutputStreamfos=newFileOutputStream(file);fos.write(largeByteArray);fos.close();//发送广播，传递文件路径（或URI）Intentintent=newIntent("com.example.MY_ACTION");intent.putExtra("data_file",file.getAbsolutePath());sendBroadcast(intent);```在接收端，读取该文件获取数据。注意事项：-文件读写要注意权限和同步问题。-及时删除临时文件。如果上述方法无法解决问题，可能需要深入分析具体场景。由于错误信息中提到“Crashingit”，可能是系统主动终止了接收进程，因此需要确保接收进程的稳定性。根据引用[2]中提到的，sendBroadcast方法本身不会抛出RemoteServiceException，这个异常可能是系统在传递广播过程中内部抛出的，所以我们应该从优化广播发送和接收入手。如果问题仍然存在，请提供更详细的日志和代码片段以便进一步分析。相关问题：1.如何避免在Android中因为广播数据量过大导致的问题？2.Android中进程间通信（IPC）的方式有哪些？各自适用场景是什么？3.如何优化广播接收器的性能以避免ANR？4.如何分析Android系统日志（logcat）来解决此类问题？</think>### 解决 "scheduleCrash for 'can't deliver broadcast' failed" 错误方案 该错误发生在 Android 系统无法向目标应用传递广播时，系统尝试终止目标进程但失败。以下是根本原因分析和解决方案： #### 核心原因分析 1. **广播数据过大** - 广播 Intent 携带数据超过 Binder 传输限制（通常 1MB） - 导致系统抛出 `TransactionTooLargeException` 变体错误[^2] 2. **目标进程异常状态** - 目标应用处于冻结/阻塞/崩溃状态（如 ANR） - 进程 PID 存在但无法响应广播（示例中的 com.baidu.launcher）[^1] 3. **广播超时机制** - 系统广播队列（BroadcastQueue）默认 10 秒超时 - 超时后触发 `scheduleCrash` 强制终止进程[^1] #### 解决方案 **1. 优化广播数据传输** ```java // 错误方式：传递大数据 Intent intent = new Intent("BIG_DATA_ACTION"); intent.putExtra("image_data", largeByteArray); // 可能超过 1MB // 正确替代方案： // 方案1：使用文件描述符传递 ParcelFileDescriptor pfd = ParcelFileDescriptor.open(file, MODE_READ_ONLY); intent.putExtra("data_fd", pfd); // 方案2：使用 ContentProvider intent.setData(Uri.parse("content://com.example.provider/data123")); ``` **2. 优化广播接收处理** ```java public class MyReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { // 避免主线程耗时操作 new Thread(() -> { // 异步处理复杂逻辑 processBroadcastData(intent); }).start(); } } ``` **3. 关键配置调整** - **AndroidManifest.xml 优化：** ```xml <receiver android:name=".MyReceiver" android:directBootAware="false" android:process=":broadcast_worker" <!-- 独立进程 --> android:exported="false"/> <!-- 最小化暴露 --> ``` - **发送端优化：** ```java // 添加 FLAG 避免后台延迟 intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); // 控制接收范围 intent.setPackage("com.target.app.package"); ``` **4. 诊断工具** ```bash # 检查广播队列状态 adb shell dumpsys activity broadcasts # 监控 Binder 事务大小 adb shell dumpsys activity service all | grep "Binder transaction" ``` #### 预防措施 1. 广播数据遵循 `10-100KB` 最佳实践 2. 使用 `LocalBroadcastManager` 替代系统广播 3. 重要广播添加超时重发机制： ```java private void sendBroadcastWithRetry(Intent intent, int maxRetry) { new Handler().postDelayed(() -> { if (!isDelivered && retryCount < maxRetry) { sendBroadcast(intent); retryCount++; } }, 2000); // 2秒重试 } ``` > **关键提示**：当出现 `ProcessRecord.kill, reason = scheduleCrash` 日志时[^1]，表明系统已判定目标进程不可恢复，此时应优先检查目标进程的健康状态（内存泄漏/死锁等），而非广播发送逻辑。 ### 相关问题 1. Android 广播传输的数据大小限制具体是多少？不同版本有差异吗？ 2. 如何检测和定位 Android 应用中的 BroadcastReceiver 性能瓶颈？ 3. 除了广播，Android 还有哪些高效的跨进程通信方式？ 4. TransactionTooLargeException 在哪些场景下会发生？如何避免？ [^1]: BroadcastQueue 日志显示无法传递广播导致进程强制终止 [^2]: RemoteServiceException 分析表明大数据量传输是常见诱因
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值