To unregister a listener from a port, you can do:
app.port.unsubscribe(myListener)
Is there a way to unregister all the listeners to a given port, without calling unsubscribe explicitely for each one? I would like to be sure I won't forget any listener.
I tried by calling unsubscribe() without any parameter, but it does not seem to have any effect.
This is not currently possible. You can see the exposed API for ports here:
https://github.com/elm/core/blob/de38986116bd93affc1c7a12e548d1f01be9a9f1/src/Elm/Kernel/Platform.js#L343-L365
The subs array is not exposed, so by default, there's no way to get at it without having the original callback.
If this functionality is important to you however you might consider writing a wrapper on the Javascript side that keeps track of your subscribed callbacks for you, which you could use to implement an unsubscribeAll yourself.
Related
I have a notification service that handles events and publishes them to clients using various technologies, such as SignalR. I want every instance of my notification service to pick up and handle these events. However, NServiceBus only allows any one instance of my notification service endpoint to pick up the event, and the other instances never get it.
My current workaround for this is to create a separate named endpoint for each instance of my notification service (the name has the server host name added to it), but then I have to make sure I unsubscribe from the event when the instance goes down or is moved to another server.
Is there a better way to do this? It would be nice if I could configure NServiceBus to create a separate incoming queue for each endpoint instance in this case, but I can't figure out how to do that, or even if NServiceBus supports such a use case.
You are correct. NServiceBus does not support such a case. Subscribers are always treated as logical endpoints, so individualized queues would not be used even if they were available.
Differentiating the instances by modifying the endpoint name is the most straightforward way to achieve what you want.
Changing your differentiator to a controllable runtime value, for instance an environment variable, would at least alleviate the need to unsubscribe when an instance is moved.
Also, if you want to review the scenario in more detail please don't hesitate to reach out to us directly, we might have other approaches to suggest. Just open a support ticket.
If a call is incoming when using a Client Browser (twilio.js) and I am already connected to an active call in the Client Browser. Client Browser doesn't ring or given any indication of an incoming call while I'm already on a call with someone else.
Is this a bug? What can be done about it so I can tell if there is an incoming call? I need to be able to answer that 2nd, 3rd, 4th, etc... incoming call should I have multiple people calling my Twilio number at the same time.
Kind of a late reply but you can use the Enqueue verb to place your callers in a queue, and then use the REST API with a javascript setInterval to list the callers in the queue. After that you can dequeue them with a Dial method or via the REST API.
We have crafted call-center functionality in node using a similar method where callers are placed in a queue which triggers a setInterval loop that monitors the queue for its members, and also looks for available agents to call.
For anyone interested I have solved this problem for myself, but in a different way to what #Ding suggests.
I'm not sure if the API has changed since this questions but you are able to access multiple Connections from a single Twilio.Device(). See this question for more details: Twilio call routing/management for small customer service team
I am using Ninject's bbEventBroker extension to wire up some pub/sub in my application. I have business services which publish events, and then I have other classes which subscribe to events. The wiring with Ninject is working, with one problem. I don't see an obvious place where I should instantiate the event subscribers. Right now I am hacking it is, and just making sure all of the subscribers are requested into the kernel as singletons before anyone else uses it. But this doesn't seem right. If I do nothing, then there are no instances of the subscribers, and the events end up getting ignored.
How should I instantiate the subscribers to bbEventBroker events so that they end up wired into the kernel?
The bbvEventBroker assumes that your subscriber is already instantiated and registered on the EventBroker. You might want to look at Ninject.Extensions.DependencyCreation as a means of managing your subscriber's lifecycle. I've successfully used this in an MVP application, to ensure that all my presenters (i.e., bbvEventBroker subscribers) where instantiated when the application starts.
I ended up creating some pretty hacky code to solve this, but it does work. In my Ninject module which wires up the event subscribers, I also add an OnActivation handler for IEventBroker. When that activation handler is called, I do a Get on the Kernel for each subscriber (by using reflection to find the right types). This ensures that an instance of each subscriber is wired into the broker.
This leads to an issue where, for some reason, IEventBrokers can be activated while Ninject is trying to dispose. So, I had to override OnDispose on my module and set a flag to stop doing the above once dispose has started. Hacks upon hacks! :-)
I have a feature I'm attempting to implement using NServiceBus but not sure the pattern to use here. (I'm fairly new to NServiceBus)
I'll try to explain where my uncertainty comes from:
User interaction triggers MVC controller to send a command to perform a domain operation. This command raises an event to notify others that this occurred.
A handler that subscribes to this event determines whether or not another domain operation should occur.
This is where I'm unclear as to the proper pattern to follow. At this point should the event handler:
just make the changes required?
send a new command to do it? If so, send it back to the originating service/process?
another option?
Part of me is wondering if I should be using an in-proc domain event to handle this, but I don't think the first command should have to wait on the second one before it returns. In fact it could happen much later. That is why I went the route of using the bus to handle it async. Also, an email will need to be generated once the second operation finishes. Should that be triggered from yet another event/command?
Any and all guidance appreciated.
If there is no need to wait for the second action then yes, it should be done asynchronously so the processing of the first command should publish an NServiceBus event. The handler for that event would (likely) be hosted in a separate endpoint which would then just do the work - no need to send another command there.
To add to Udi's answer, I would only turn around and send a command back to the originating service if the service at the originating endpoint is really the one that should be responsible for the behavior of that command. Otherwise, the service (endpoint) receiving the event should just do what it needs to do in response to the event (which sounds like your case).
I'm writing an API which is used to receive some data from another application. Currently the function is designed to block until data is received. In my mind this limits developers using the API to use multithreading or some sort of multi-process design. So is it better for a function to block or to return a null and then sleep for a few milliseconds before trying again.
Note the other application may not have any data to send through the API for an unknown period of time.
The API is written in C++
Why not use a callback?
You could define the API to allow the user to pass an optional timeout value. If the timeout is not specified, then the API function waits indefinitely, much like how select() works.
Consider another option: use an async transaction -> issue a request & provide a callback address with ticket id. When the response is available, the service end-point callbacks your application with the ticket id and of your the result ;-)
You should avoid as must as possible blocking when you possibly can.
As you say:
Note the other application may not have any data to send through the API for an unknown period of time.
In this case, using a synchronous interface ties up resources unnecessarily.
You haven't said what language this is, but it sounds like your API is listening or checking for some event, and the users of the API are either blocking or polling your API to determine if the event happened?
Is it possible to use a callback? Users of the API would register for notifications of the event happening, and when your library detects the event it will use the callback to notify all listeners.
When your applications calls the O/S api function read(), do you expect it to block? Of course you do—at least by default. In some circumstances, ioctl's allow a programmer to change the behavior to be asynchronous, which is particularly common in network applications.
You've shed very little light on what your API is about, so consider:
Does it make sense that an API user would want to be blocked? That is, is there little to do until it returns.
If you were writing an application for the API, what would you expect it to do? You should definitely write a few sample applications for your own education, as well as to document the API.
Is there any reason why the API user would not multithread (or fork, etc.) requests to the API?
If you want a reusable solution you could apply the Asynchronous Design 'Pattern' which is common in .NET but can also be implemented in C++ as demonstrated in this CodeProject project.
There's nothing wrong with providing both synchronous and asynchronous calls to the same feature in the interface.
Personally I would only go these lengths if I need to service multiple requests (in which case you can queue 'BeginOperation' requests for example), or there are many potentially asynchronous operations in the interface (and I want a standardised, flexible pattern). If you can only handle one request at a time a time-out is usually sufficient.