问题标签 [message-queue]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
windows - windows server 企业消息队列系统
我正在寻找一个在类似于 jms 的 windows 服务器上运行的消息队列系统。
ssl - 如何使用 MQ 的 ssl 证书打开 kdb 文件?
IBM MQ 使用了一些对我来说很奇怪的带有 kdb 扩展名的证书格式。
如何打开它并更改其有效期?
msmq - 消息平台
我们正在考虑在银行环境中集成两个核心系统的消息传递平台。我们正在研究开源选项。您使用过哪些产品,可以分享经验吗?
linux - 消息队列在 linux 中过时了吗?
我最近一直在 Linux 中使用消息队列(System V,但 POSIX 也应该没问题),它们似乎非常适合我的应用程序,但是在阅读了 The Art of Unix Programming 我不确定它们是否真的是一个不错的选择.
http://www.faqs.org/docs/artu/ch07s02.html#id2922148
System V IPC 的上层消息传递层已基本停止使用。下层由共享内存和信号量组成,在需要在同一台机器上运行的进程之间进行互斥锁定和一些全局数据共享的情况下,仍然有重要的应用。这些 System V 共享内存设施演变成 POSIX 共享内存 API,支持 Linux、BSD、MacOS X 和 Windows,但不支持经典的 MacOS。
http://www.faqs.org/docs/artu/ch07s03.html#id2923376
System V IPC 设施存在于 Linux 和其他现代 Unix 中。但是,由于它们是遗留功能,因此它们并不经常使用。到 2003 年中期,Linux 版本仍然存在缺陷。似乎没有人足够关心来修复它们。
System V 消息队列在最近的 Linux 版本中是否仍然存在错误?我不确定作者是否意味着 POSIX 消息队列应该没问题?
似乎套接字是几乎所有东西的首选 IPC(?),但我看不出用套接字或其他东西实现消息队列是多么简单。还是我想的太复杂了?
我不知道我使用嵌入式 Linux 是否相关?
c# - 消息队列和服务总线的消息粒度
我正在开发一个应用程序,该应用程序可能会在客户端上以相当紧凑的循环生成数千条消息,并在服务器上进行处理。事件链类似于:
- 客户端处理项目,放置在本地队列中。
- 本地队列处理拾取消息并调用 Web 服务。
- Web 服务在服务器上的服务总线中创建消息。
- 服务总线将消息处理到数据库。
这个想法是所有通信都是异步的,因为 Web 服务将有许多客户端。我知道 MSMQ 可以直接执行此操作,但我们并不总是在客户端上拥有那种管理能力来设置安全等内容。
我的问题是关于每个阶段消息的粒度。最简单的方法意味着客户端上处理的每个项目都会生成一个客户端消息/Web 服务调用/服务总线消息。这很好,但我知道如果可能的话,最好对 Web 服务调用进行批处理,除非在大粒度 Web 服务 DTO 与数据库上的短期运行事务之间进行权衡。这个特定场景不需要“业务事务”,其中处理所有或不处理任何项目,我只是希望在消息大小与 Web 服务调用数量与数据库事务之间实现最佳平衡。
有什么建议吗?
asynchronous - 实现可靠异步消息访问的服务版本控制的权衡?
HTTP 服务的客户端可以通过请求或发布具有特定内容类型的数据来指定他们理解的版本(和格式)。HTTP 协议定义了用于报告内容类型不被理解的错误代码。
消息系统(例如 JMS、MQ 系列等)没有描述消息协议版本和内容格式的标准方式。
您如何为通过可靠的异步消息传递访问的服务实现版本控制?
一些可能性:
- 发件人将版本指示为消息属性
- 队列或主题名称包括在该目的地接受的消息的协议版本
- 版本在消息的有效负载中
我敢肯定还有其他方法。你是怎么做到的?你发现了哪些优点和缺点?
c# - 使用因消息类型而异的处理资源来使用队列的消息
我在为异步队列消费者线程组合算法时遇到了一些麻烦,即从单个队列中读取需要分派以执行长时间运行(至少几秒钟)工作的项目。
基本上队列可以如下所示:A,A,A,A,A,B,B,A,B,A,A,A,A,A,C,B,A。
IE。A 消息比其他消息更常见。
我们的系统对每种不同的消息类型都有不同的并发值,例如我们一次只能执行 3 x A 消息,但我们可以同时执行 5 x B 和 4 x C 消息。
我当前的(损坏的)算法是让一个线程从队列的前面读取并将每个作业分派到线程池,每个作业的主体在执行实际有效负载之前等待足够的资源可用。
这意味着如果足够多的 A 消息首先到达,那么它们可以“填满”线程池的队列,并且 B+C 消息的饥饿时间比需要的时间长得多。
到目前为止,我已经考虑为每种消息类型(类型数量相当少)设置一个单独的线程池,但我担心保留这么多线程的效率。
关于如何改进这一点的任何建议?
scala - Scala 演员作为单线程队列
我想在一个节目中使用演员,在这个节目中,我会对一些演员进行某种限制,就好像他们是队列一样。例如,假设我有一些应用更改事件的外部系统以及一些外部系统数据的缓存。所以我有2个演员:
ChangeApplicationActor
CacheActor
作为 的一部分ChangeApplicationActor
,当我对外部系统中的某个实体应用更改时X
,我想发送一些事件来告诉CacheActor
同步:
但我现在有两个要求:
- 具有
CacheActor
内部状态,理想情况下我希望它Sync
按顺序处理其指令 - 如果我最终在
CacheActor
收件箱中包含两个Sync(x)
相同值的指令x
,那么我想忽略第二个(即Sync
对于任何给定的值,我应该只有一个待处理指令x
)
有没有办法强制一个演员是单线程的?有什么方法可以访问演员的邮箱并删除任何重复的事件?我不能避免实现CacheActor
as, um, not an Actor吗?
wcf - 事务超时后如何在 WCF 中停止执行方法调用
我使用包含很长循环的方法创建了一个测试服务。我希望当发生超时事务时,方法执行会刷新,但事实并非如此。客户端获得超时,但处理在服务器上继续。
有没有办法阻止它?不改变方法代码?
这是示例:在示例中,我使用队列绑定调用方法 QueueRequest,10 秒后事务中止。此时会发生重试,导致同样的问题。几次重试后,服务器正在执行 100% 的 cpu 工作,试图在多个线程/实例上运行循环,即使消息已中毒并被丢弃。
c++ - 如何在等待时保持消息泵送?
我有一个基于消息泵线程池架构的应用程序。每当有可能阻塞的动作时,它都会被实现为“完成/触发 evnet 时的回调”动作,因此它不会停止正在执行的线程。
虽然这种技术适用于大多数情况,但在某些情况下它会变得非常不方便并且会使代码过于复杂。
我想做的是,在等待时以透明的方式继续处理事件,而不会将功能分解为等待前/等待后的部分。
我该怎么做?
我有两个选择:
- 在等待时从正在执行的函数中运行消息循环。
- 在等待时创建一个新的工作线程,并在恢复时(以适当的方式)终止它。
这两种选择都有其缺陷,仅举几例:
对于 1:
- 可能会导致堆栈溢出。
- 可能最终陷入僵局。
- 如果内部消息导致等待第二个事件完成,而外部事件同时完成,则外部函数在第二个事件完成之前无法继续,这种情况可能会扩大。
选项 2 最终会导致创建越来越多的线程。
当然,可能还有其他我没有想到的选择。
编辑:语言是 C++,所以函数不能以简单(便携?)的方式进出。平台是 Windows (API),虽然我不认为它是相关的。