I've used ZeroMQ in the past with with JVM applications via the jzmq library. I am planning on using zeromq on a new project where some of the services are implemented on the JVM. I just discovered jeromq, a pure java implementation of zeromq, and I would like to use it mostly since it is tracking zeromq 3.x and it removes the headache of dealing with jzmq. However, I can't tell from the repo page if it is production ready. Does anyone have experience with jeromq in production?
As the author of the project, I'm a little bit biased.
The reason I made jeromq was I also had some trouble with deploying jzmq having JNI.
The project has a short history but keep improving from feedbacks and contributions.
But it's not a replacement of jzmq. Both project are active and driven by a major community. You can get help from the community and contribute to the projects also.
From the 3.0-SNAPSHOT, it has a API level compatibility. You can switch between jeromq and jzmq easily without changing your code.
Why not write a JNI that would do all the interaction with 0MQ ? This would bring the problem in your hands instead of hoping for some 3rd party library being mature enough or production-ready.
That's what I'd do. The C/C++ API of zeromq is IMHO the most mature of them and, as such, I think it would bring you the most benefit.
Writing a JNI is not hard either so I think this would be a good way to go.
Related
Months ago I was selecting .NET library to use for implementing ZeroMQ communication, and I was pretty confused with the fact that there are few libraries suggested at zeromq.org.
Meanwhile I've learned few things, so I'll share here. Someone may find this helpful. So let me ask myself:
What is the difference between NetMQ and clrzmq?
(Although I'll answer this myself, if anyone else has some experience on the subject - alternative answer is welcome!)
The key difference between the two is in the approach:
CLRZMQ is binding project which actually uses libzmq library in background (it's a .NET wrapper for libzmq library);
NetMQ is .NET-native port of ZeroMQ, meaning that it does not wrap existing libzmq but rewrites it in pure C#.
Which one to use? Well, there's no simple answer. Here are few important things to keep in mind while choosing:
When it comes to portability - NetMQ wins by far, especially due to the fact that there's .NET Core version of NetMQ. Deployment is also easier with NetMQ - there are no native libraries to worry about (x64 / x86, etc.).
On the other side the fact that NetMQ actually rewrites everything is bit scary for me - there's always risk that something is not precisely mirrored from the original code, and that it may cause incompatibility with other ZeroMQ nodes. There's also question how fast NetMQ will implement new features from the original library.
Performances. At the moment I don't know which library wins in performances, but this is definitely thing to consider while choosing. libzmq should be significantly faster than any managed code, but in communication between CLRZMQ and libzmq marshaling has to take place, so I really can't predict which library will win in speed.
UPDATE: Another important advantage of NetMQ is support - You'll get the answer in up to day or two, and sometimes within hours.
UPDATE 2: A problem with poller implementation in NetMQ (described here) turned out to be show-stopper problem for NetMQ in my case. Due to this problem I've migrated my projects to CLRZMQ (I may change my mind down the road...) Nevertheless, talking about poller, there's one problem in CLRZMQ documentation you should be aware of, and it's described here
According to Doron Somech:
http://somdoron.com/2013/03/introducing-netmq/
As of 2014 C# binding (CLRZMQ) is no longer maintained and NetMQ is the default choice for ZeroMQ and .Net.
It seems that:
https://github.com/zeromq/clrzmq4
replaced the original CLRZMQ project.
I'm using NetMQ and looking forward to contribute to the project.
P.S. I build same Pub-Sub scenario for NetMQ and native ZeroMQ and didn't find any performance difference. Great work, Doron!
There are several XMPP client libraries for Ruby available, what is your experience with them and which one would you recommend?
What kind of thing are you looking to write in XMPP? The choice very much depends on what you want to do. These are the ones I have had experience of:
XMPP4R is one of the most popular. However the project is no longer actively maintained. I've always found the API to be a little clunky.
Blather, really cool DSL for writing things. Relies on EventMachine, so nice, fast and simple. However may not play nicely if you want to use in a non-evented webserver (like Passenger). It is also difficult to work with in an IRB console, which can make experimenting harder.
There are a few projects which build upon these base libraries for creating things like bots, Although I've no experience of them.
For the project I work on we communicate extensively from within Rails so use our own thing (Jubjub, and xmpp_gateway). However the project is still in early days so don't expect the same kind of polish as from other libraries - it's just trying to solve a different problem, and works for us.
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.
I'm somehow familiar with the ASP.NET MVC and the .NET framework in general (I use it at work).
I've been thinking about starting a personal project (a website). I, however, don't want to be tied to a specific platform (it bothers me A LOT).
This led me to looking into Mono. For what I've seen, though, Mono trails behind Microsoft's .NET in some aspects that are crucial to me (or that I would really like to have available). Some of these are:
LINQ to SQL. The Mono team just now (Mono 2.6) released support for LINQ with help from the DBLinq project. The problems are that DBLinq's main test platform are MS SQL SERVER and SQLite. It seems to me that PostgreSQL and MySQL are a bit abandoned. Also, LINQ to SQL has just been implemented and thus it makes me think when it will become mature.
Hosting of Mono on Linux. Very few of these are available.
Also, I want to be prepared to handle heavy-duty processing on the server (this is a main issue), and Twitter's experience makes me drift away from Ruby on Rails, but if you can prove RoR scales weel (please, show benchmarks/facts and not opinions) I'd be willing to try it.
Should I take my time learning a different web framework, or should I rely on Mono's advances and hosting options for the near future (1~2 years) on platforms other than Windows/SQL Server.
In terms of scalability, I tend to think that C# has an inherent aspect of scalability (strongly typed and ByteCode instead of parsed/interpreted). Am I wrong to think like that?
Are there ways to work with other frameworks in ways that the code won't be hosted on the server (I accept python/ruby/anything VMs and others)
This is an old question so I may be answering more for others than for the original poster:
Hosting
If you write in Mono, you can host on Windows, Mac, or Linux (or Solaris, FreeBSD, and others less dependably). If you are going to host on Windows though, why not just run your Mono app on the real .NET?
Why do you care if it is hosted on Mono if you are not hosting it yourself? You can certainly write an application on Mono using Windows, Linux, or Mac and then host it on a Windows/.NET host if those are the cheapest and easiest to find. Just think of .NET as the MS implementation of Mono.
I had the opposite problem originally. I wanted to host on Linux even though my employer provided a Windows dev environment. I developed in .NET and hosted on Mono/Linux. Mono worked excellently for me in this way.
My current employer is Mac crazy. I just deployed an ASP.NET MVC2 app to our Mac server yesterday. I wrote the whole thing on my MacBook Pro without touching Windows once.
My favourite host for running .NET/Mono on Linux is Linode. The cheapest plan is $20/month but I can host as many apps on the same server as I want. The performance is excellent so anything that is going to run well on a $5/month host is going to run just fine as one of four apps on a Linode instance that is for sure.
Compatibility with .NET
I find it is best to think of Mono as a platform itself rather than as a compatibility solution for your Microsoft apps. Mono supports almost the entire .NET framework. I love this because it is a great framework but I do not really care that it is MS compatible most days.
No offence, but I do not understand at all your implication of "Mono does not support LINQ-to-SQL to my satisfaction so I am considering Ruby-On-Rails". Mono supports LINQ-to-SQL a lot better than Ruby does I will tell you that. You could say that you are sticking with Windows only because you really need LINQ-to-SQL though I suppose. What is more important to you, "cross platform" or "LINQ-to-SQL"?
Mono gives you many choices for data access. If you want an ORM (Object Relational Mapper) like Rails offers then you could go for something like NHibernate, Subsonic, or Castle ActiveRecord for example. With Mono 2.10 you can even use WebMatrix Data. Of course, you could also use good 'ole ADO.NET which is what all this stuff is built on top of anyway.
Oh, and let's not lose site of the fact that Mono does support LINQ-to-SQL. I have only ever used it with SQLite where it worked fine. I agree that it has lagged .NET though. You are probably worried about Entity Framework support now. See my comments above.
To my mind, the question is how does Mono data access compare to Rails data access. My answer: Rails is a bit better integrated (simpler) and Mono is much more powerful and flexible.
Heavy-duty processing
This is where .NET and Mono are really going to shine.
You are correct to think that compiled bytecode is going to be much faster than interpreted code and that static languages like C# will be faster than dynamic languages like Ruby. Of course, everything is implementation dependent in the end.
I also agree that a static language like C# aids scalability in other ways. This is really a matter of personal opinion though. There are certainly people that think that authoring and maintaining a massive solution in a dynamic language is feasible. I do not see many people doing that of course. There is a reason that .NET and Java are the enterprise standards.
Bottom line
Should you learn another web framework? Well, I think you should. It is good for the mind.
Is that other web framework a superior choice to Mono or .NET? Well, it depends on the need of course. I think that Rails folks probably pump out the sites a little faster than the .NET crowd in general. The gap has really closed with ASP.NET MVC2+ though and I would much, much rather maintain and scale a .NET solution than a Rails one. Also, I like C# just fine so I do not find Ruby itself so intrinsically satisfying that I just have to use it. That is just me of course.
Also, just me, but I find Mono to be an excellent cross platform web development framework. I choose it everyday over other solutions. I also find that Mono fits into the majority of the .NET ecosystem (especially the Open Source universe) just fine. Again though, if what you really want is to use the very latest and greatest MS stuff and are hoping that Mono will allow you to run that on Linux or Mac sometimes then you may be disappointed.
If Windows Presentation Foundation (WPF), Entity Framework, or to a lesser extent LINQ-to-SQL are the most important part of your application strategy then Mono is not for you.
If you want a platform that gives you all the great advantages of .NET and runs pretty much everywhere you need it to then Mono is pretty damn hard to beat.
I am trying to get started writing scalable, telecom-grade applications with Asterisk and Ruby. I had originally intended to use the Adhearsion framework for this, but it does not have the required maturity and its documentation is severely lacking. AsteriskRuby seems to be a good alternative, as it's well documented and appears to be written by Vonage.
Does anyone have experience deploying AGI-based IVR applications? What framework, if any, did you use? I'd even consider a non-Ruby one if it's justified. Thanks!
SipX is really the wrong answer. I've written some extremely complicated VoiceXML on SipX 3.10.2 and it's been all for naught since SipX 4 is dropping SipXVXML for an interface that requires IVRs to be compiled JARs. Top that off with Nortel filing bankruptcy, extremely poor documentation on the open-source version, poor compliance with VXML 2.0 (as of 3.10.2) and SIP standards (as of 3.10.2, does not trunk well with ITSPs). I will applaud it for a bangup job doing what it was designed to do, be a PBX. But as an IVR, if I had it to do all over again, I'd do something different. I don't know what for sure, but something different. I'm toying with Trixbox CE now and working on tying it into JVoiceXML or VoiceGlue.
Also, don't read that SipX wiki crap. It compares SipX 3.10 to AsteriskNOW 1 to Trixbox 1. Come on. It's like comparing Mac OS X to Win95! A more realistic comparison would be SipX 4 (due out 1Q 2009) to Asterisk 1.6 and Trixbox 2.6, which would show that they accomplish near identical results except in the arena of scalibility and high-availability; SipX wins at that. But, for maturity and stability, I'd advocate Asterisk.
Also, my real world performance results with SipXVXML:
Dell PowerEdge R200, Xeon Dual Core 3.2GHz, handles 17 calls before jitters.
HP DL380 G4, Dual Xeon HT 3.2 GHz, handles 30 calles before long pauses.
I'll post my findings when I finish evaluating VoiceGlue and JVoiceXML but I think I'm going to end up writing a custom PHP called from AGI since all the tools are native to Asterisk.
You should revisit Adhearsion as v0.8.1 is out, and the documentation has gotten much better quite recently. Have a look here:
http://adhearsion.com
http://docs.adhearsion.com
http://api.adhearsion.com
If you're looking for "telecom-grade" applications, you may want to look into SipXecs instead of asterisk. It's featureful, free, and open source, with commercial support available from Nortel. You can interact with it via a Web Services API in ruby (or any other language).
See the SipXecs wiki for more information. There's a comparison matrix on that site, comparing features with AsteriskNOW and TrixBox.
There really aren't any other frameworks out there. There's of course AGI bindings to every language, but as far as full-fledged frameworks for developing telephony applications, we're just not there yet. At least in the open-source world.
I have asked somewhat related questions here, here, and here. I'm using Microsoft's Speech Server, and I'm very intested to learn about any alternatives that are out there, especially open source ones. You might find some good info in the answers to one of those questions.
I used JAGIServer extensively, even though it's not under development anymore, and it's pretty good and easy to use. It's an interface for FastAGI, which I recommend you use instead of simple AGI.
The new version of this framework is OrderlyCalls which seems to have a lot more features but since I haven't needed them, I haven't tried it.
I guess it all depends on what you want to do with AGI; usually I have a somewhat complex dialplan to gather and validate all user input and then just use AGI to connect to a Java application which will read some variables, do some stuff with it (perform operations, queries, etc etc) and then sets some more variables on the AGI channel and disconnects. At this point, the dialplan continues depending on the result of the variables set by the Java app.
This works really fast because you have a ServerSocket on the Java app, which receives incoming connections from AGI, creates a JAGIClient with the new socket and a new instance of a JAGIProcessor (which you have to write, it's the object that will do all your processing), and then run the JAGIClient inside a thread pool.
Your JAGIProcessor implements the processCall method where it does all the work it needs, interacting with the JAGIClient passed as a parameter, to read and set variables or do whatever stuff the AGI interface allows you to.
So you have a Java app running all the time and it can be a simple J2SE app or an EE app on a container, doesn't matter; once it's running, it will process AGI requests really fast, since no new processes have to be started (in contrast to simple AGI which runs a program for every AGI call).
Smee again. After migrating my client's IVR's over from SipX to Asterisk utilizing PHPAGI, I must say that I haven't encountered any other architecture that anywhere near as simple and capable. I'll be stress testing Trixbox CE 2.8 today on the same hardware I had tested SipX on earlier. But I must say, using PHPAGI for the IVR and the Asterisk CLI for debugging has worked perfectly and allowed me to develop IVR's far faster than any other company out there. I'm working on implementing TTS and ASR today and I'll post my stress test results when I can.
Simple small flexible Asterisk AGI IVR written on PHP
http://freshmeat.net/projects/phpivr
For small and easy applications I use Asterisk::AGI in perl. There are also extensions for the Fast AGI. For bigger applications, like VoIP operator's backends I use something similar to OrderlyCalls written in Java (my own code). OrderlyCalls is great though to start with java fastagi engine and extend it to your needs.