i have used erlang for the passed five month and i have liked it now it is my time to write down a concurrent application that will interact with the YAWS web server and mnesia DBMS and to work on a distributed system may any one help me with a sketchy draft in Erlang?
i mean the application should have both the sever end and the client end where by the server can accept subscriptions from clients, Forwards notifications from event processes to each of the subscribers, accept messages to add events and start the needed processes, can accept messages to cancel an event and subsequently kill the event processes. whereas the client should be able to ask the server to add an event with all its details,ask the server to cancel an event, monitors the server (to know if it goes down) and shut down the event server if needed. The events requested from the server should contain a deadline
Spend some time browsing github, you can find projects corresponding to your description:
http://www.google.ca/search?hl=en&biw=1405&bih=653&q=site%3Agithub.com+erlang+yaws+mnesia&aq=f&aqi=&aql=&oq=
Related
I need to handle a time-consuming and error-prone task (e.g., invoking a SOAP endpoint that will trigger the delivery of an SMS) whenever a given endpoint of my REST API is invoked, but I'd prefer not to make my users wait for that before sending a response back. Spring AMQP is already part of my stack, so I though about leveraging it to establish a "work queue" and have a number of worker processes consuming from the queue and taking care of the "work units". I have, however, the following requirements:
A work unit is guaranteed to be delivered, and delivered to exactly one worker.
Shall a work unit fail to be completed for any reason it must get placed back in the queue so that another worker can pick it up later.
Work units survive server reboots and crashes. This is mandatory because I won't be using a DB of any kind to store them.
I know RabbitMQ and Spring AMQP can be configured in such a way that ensures these three requirements, but I've only ever used it to achieve RPC so I don't know much about anything other than that. Is there any example I might follow? What are some of the pitfalls to watch out for?
While creating queues, rabbitmq gives you two options; transient or durable. Durable messages will be available until you acknowledge them. And messages won't expire if you do not give queue a ttl. For starters you can enable rabbitmq management plugin and play around a little.
But if you really want to guarantee the safety of your messages against hard resets or hardware problems, i guess you need to use a rabbitmq cluster.
Rabbitmq Clustering and you can find high availability subject on the right side of the page.
This guy explaines how to cluster
By the way i like beanstalkd too. You can make it write messages to disk and they will be safe except disk failures.
I'm developing an ASP.NET MVC 5 application that displays current staffing data, and uses SignalR to notify connected clients when staffing changes occur. This is working great for real-time events ("I need to leave work now."), but now I need to handle scheduled events where a staffing change will happen in the future.
That is, an event may be scheduled to occur in 3 hours and 27 minutes ("I need to leave work at 4pm") or even 3 months from now. When the event occurs, connected clients should be notified in order to display correct staffing data to the end users. Of course, the future may change, and a solution would need to account for scheduled events being canceled or modified.
I would love to find a clean way to do this that doesn't involve frequent polling from clients to learn of upcoming events, a thread on the server side that sleeps, etc.
I would create a small windows service that takes care of scheduling. Then use a service bus to signal the web server for example
http://ayende.com/blog/3752/rhino-service-bus
On the web server you can use https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy
to forward the messages directly to the clients
I'm writing a TCP server in Erlang, using Ranch. The clients will reconnect immediately the connection is dropped, which means that one particular failure mode is listeners being started and killed dozens of times a second.
I'd like to detect this happening and publish statistics to statsd, for monitoring in production.
So, can I use something in Ranch to monitor when a listener is recycled? Or can I use something in Erlang to monitor process mortality for the entire node, without having to link to each process, and where those processes were started by some other supervisor, so I don't have a reference to them?
It's not a direct answer to my question, but I opted, instead, to have a separate process periodically polling ranch_server:count_connections(my_ref), and publish that to statsd.
I have a supervisor with N worker processes. As usual the supervisor can send a message to a worker process and there is a handle_cast that sends a reply from a worker to the supervisor.
How can I check that exactly all N workers have replied to the supervisor? Is it possible to implement this with any kind of event handling - i.e. to tell the supervisor "Ok, everyone has replied" and not to make the supervisor to check for the "All N processes have replied" status every second in some kind of ETS child registry table?
If you are talking about an OTP supervisor, no you can't send a message to a worker from it. A supervisor is a very limited behavior with the purpose of starting, monitoring, restarting and stopping processes. Nothing else.
So to solve your particular problem, you would have to have a process that is responsible for sending a message to all workers. This process could also keep a list of all workers in its state, "tick off" (or remove from the list) the workers that have responded. You can achieve this with a list of PIDs, and receiving responses from the processes (or by monitoring the processes with erlang:monitor/2 if they're exiting when they're done) and see who's left.
An alternative - which could (or could not) apply to your case is to use the gen_event behaviour.
DISCLAIMER
I say "could" because it depends on what your "workers" do in your specific case. If you're interested in the content of their replies, you might prefer not to use this approach, but in the case you're interested just in the fact that all the workers completed their tasks - for example the worker processes do some heavy calculation and store their partial result on a database, so you're ready to combine the partials - the gen_event could be the route to go.
END OF DISCLAIMER
So...
In OTP, an event manager is a named object to which events can be sent.
Events are messages.
In the event manager, zero, one or several event handlers are installed. When the event manager is notified about an event, the event will be processed by all the installed event handlers.
So, basically, instead of having one supervisor and several workers, you have an event manager and several event handlers.
You could then use the gen_event:sync_notify/2 function:
sync_notify is synchronous in the sense that it will return ok after
the event has been handled by all event handlers.
For more information about the *gen_event* look here and there.
I wonder what is the best approach to handle the following scenario:
I have a server that is designed to handle only 10 connections at a time, during which the server is busy with interacting with the clients. However, while the the server is busy, there may be new clients who want to connect (as part of the next 10 connections that the server is going to accept). The server should only accept the new connections after it finishes with all previous 10 agents.
Now, I would like to have an automatic way for the pending clients to wait and connect to the server once it becomes available (i.e. finished with the previous 10 clients).
So far, I can think of two approaches: 1. have a file watch on the client side, so that the client will watch for a file written by the server. When the server finishes with 10 clients, it will write the file, and the pending clients will know it's time to connect; 2. make the pending clients try to connect the server every 5 - 10 secs or so until success, and the server will return a message indicating whether it is ready.
Any other suggestion would be much welcome. Thanks.
Of the two options you provide, I am inclined toward the 2nd option of "Pinging" the server. I think it is more complicated to have the server write a file to the client triggering another attempt.
I would think that you should be able to have the client waiting and simply send a READY signal. Keep a running Queue of connection requests (from Socket.Connection.EndPoint, I believe). When one socket completes, accept the next Socket off the queue.