I am in trouble finding API for the "local Erlang client" for Riak.
Here is what Riak wiki says:
The local Erlang client is a tightly-integrated part of Riak and the Riak REST interface uses the Erlang client internally. You can find more information about the Erlang-native driver in the edoc API.
The link redirects to the main wiki-page. There is plenty of information on PBC Client though.
How do both clients compare and what are the pros and cons in using one or another?
The API for the native erlang client or edoc is found here
But I would second what Dan says. However, note that the PBC is still very much at the alpha stage of development and as far as I know does not yet have map reduce capabilities.
I would recommend using the PBC client. The performance is comparable to the native erlang client. It is also easier to decouple your application code from Riak. The native erlang client requires the entire Riak code base as a dependency.
From Riak 2.0 and on, it is highly recommended to use PB (Protocol Buffers) APIs over HTTP APIs. They have become a primary APIs, have more functionality and also is faster than HTTP APIs.
Getting Started with Erlang client
GitHub repo for official Riak Erlang client
Related
I've recently started understanding the Spring Cloud Data Flow, also called as SCDF. I've just started looking at https://codenotfound.com/spring-batch-admin-example.html which seems very nice example, also would need more examples to really understand the use of Spring Cloud Data Flow with Spring Batch, as I've good experience with Spring Batch.
What's the difference between spring-cloud-starter-dataflow-server (Data Flow Server Starter) and spring-cloud-starter-dataflow-server-local (Local Data Flow Server Starter) ?
We used to ship spring-cloud-starter-dataflow-server-local as a standalone uber-jar for local deployments a few years ago. Similarly, we used to have spring-cloud-starter-dataflow-server-kubernetes, spring-cloud-starter-dataflow-server-cloudfoundry, and others.
However, we have consolidated all the supported platform implementations of SCDF into a single uber-jar, and that is spring-cloud-starter-dataflow-server. Please only use this artifact for any development/deployment, even if it is only used locally.
As for feature capabilities, we have a dedicated page that lists them. Once you dig into the relevant sections ranging from developer guides [example: batch developer guide] to recipes, hopefully, you will have an idea.
And, likewise, you might find the architecture and concepts useful for your research, which will cover the broad set of capabilities that SCDF supports including first-class orchestration experience for Spring Batch workloads.
How does AppDynamics and similar problems retrieve data from apps ? I read somewhere here on SO that it is based on bytecode injection, but is there some official or reliable source to this information ?
Data retrieval by APM tools is done in several ways, each one with its pros and cons
Bytecode injection (for both Java and .NET) is one technique, which is somewhat intrusive but allows you to get data from places the application owner (or even 3rd party frameworks) did not intend to allow.
Native function interception is similar to bytecode injection, but allows you to intercept unmanaged code
Application plugins - some applications (e.g. Apache, IIS) give access to monitoring and application information via a well-documented APIs and plugin architecture
Network sniffing allows you to see all the communication to/from the monitored machine
OS specific un/documented APIs - just like application plugins, but for the Windows/*nix
Disclaimer : I work for Correlsense, provider of APM software SharePath, which uses all of the above methods to give you complete end-to-end transaction visibility.
I read this question but was somehow not satisfied with the answers.
I also quickly read (as suggested in that question) the last chapter of Marco Cantù 2010 Handbook, from which I quote the following (I think I can quote such a short text):
I [Marco Cantù] do have a lot of
investment in server side web and REST
applications written in Delphi, and in
the recent years I've started playing
with and introducing at conferences a
Delphi Web Application REST
Framework119 (that is, DWARF), which
at this time is still not publicly
available... simply because it is too
sketchy and unfinished to be
published. I've seen other ongoing
efforts to clone Rails in Delphi and
offer other REST server architectures.
I think that if you want to build a
very large REST application
architecture you should roll out your
own technology or use one of these
prototypical architectures.
Considering that I own Delphi XE Professional and DataSnap is not in there and I would like to consider to write large applications too according to the above comments it seems DataSnap is not an option.
Is there even a commercial solution for this? I don't want to consider "my own implementation of REST", I would like to create a webserver that uses some of my datamodules where I use the DAC I choose (Devart in this case).
Final note: my goal is to write the backend for a large web application, on the client I would like to use Ext JS 4.0, but I want to do all the client work in javascript, to take full advantage of EXT JS, so basically I need a webserver just for the data and tracking the state, not for serving webpages.
To create your REST services, try our Open Source mORMot project. Now it is a well known and stabilized project, used world wide in production.
You can use any DAC with the current state of the framework by implementing a custom TSQLRestServerStatic class (similar to the TSQLRestServerStaticInMemory class, but calling your DAC): so you'll benefit for the ORM and the JSON RESTful architecture, together with the high-speed http.sys kernel-mode server.
The SQLite3 engine is NOT mandatory with our framework, even if it was designed to work better with it.
If you will start an application from scratch, I think the mORMot is a good option if Delphi is your only option. If you choose datasnap you'll have to live with the problems of performance and stability.
I wrote an article on my blog talking about performance and stability with DataSnap (and mORMot) in large applications, you can see it on the following link:
DataSnap analysis based on Speed & Stability tests
I think you should have a look at kbmMW, there is a way to implement a basic REST server based on an event driven HTTP server.
Check news.components4developers.com news groups, there you will have a lot of documentation.
FireHttp is a high-performance Web server based on Delphi/Object Pascal language. It supports HTTP 1.1, HTTPS (SSL/TLS), WebSocket, GZip, Deflate, IOCP, EPOLL. It adopts multi-process+multi-threading model, has good stability and concurrency performance, and provides SDK source code. Developers can use SDK to quickly build high-performance cross-platform Web applications.
Just started reading the OTP chapter on the great Erlang book by Francesco Cesarini. Are most Erlang applications such as MochiWeb, Riak, RabbitMQ, Zotonic, ejabberd and CouchDB OTP applications?
CouchDB had lot of problems with that but the newest sources published by Cloudant show CouchDB in rebar, so it must be otp compliant.
Riak - the same, on rebar (btw. the same devs rebar and riak). Btw2. it is very nicely written app, good place to learn good practices.
Zotonic source code looks like mess a little bit. I can see there 'application' etc. but directory structure do not look like any proper OTP node. Btw. even Licence is not added on the top of all modules :?
ejabberd is full of sups and apps, but it has also some interesting;) design choices, so maybe do not learn Erlang on this example.
The Hibari database app is definitely OTP-based. The server is broken into several OTP apps, including a small one for managing config and logging (gmt), a big one for the server itself (gdss), a small one for native Erlang clients (gdss_client), and separate OTP apps for each of the server-side protocol handlers (e.g. JSON-RPC, UBF, EBF/BERT).
Sometimes a picture is worth at least a few hundred words. I've got some screen captures from the Erlang "appmon" (application monitor) app that shows the supervisor-and-worker process tree. Sorry, the protocol handler apps aren't shown in image #01, but they would be if I had had them running when I captured the image.
The link is here: OTP 'appmon' screen shots
-Scott
MochiWeb follows basic OTP Design Principles: it utilizes supervisor(3) behaviour to restart crashed processes (module mochiweb_sup.erl), and gen_server(3) behaviour. However it implements many routines to process data, such as ones found in mochinum.erl for faster floating point numbers serialization and mochijson[2].erl to process JSON etc.
The bad thing with mochiweb (I made it clear why here) IMHO is that it uses questionable and officially undocumented (since 2003!) technique of modules parameterizing (module mochiweb_request.erl, notice -module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]). in the head of the file). The same applies to another Erlang HTTP-library misultin (misultin_req.erl).
Correct me if I'm wrong.
I am a newbie to Erlang and am trying to make a switch to Erlang for our latest project. Since this is going to be a real-time chat (long polled) system for file sharing on the fly, I realized after a bit of digging around that Erlang would be the most appropriate choice, because of high concurrency, plus people also suggested to use Yaws since it can handle upto 50k parallel connections.
Although, it sounds awesome, but since I am a newbie (both to erlang and comet applications), I am unable to understand the right technology stack / architecture of how this would work. Also, because of relatively less documentation, I am unable to figure out how the individual pieces would fit together (web server, application layer, DB, message queue) for such an application. The application is going to run off a desktop client only (no web presence required), and so we need to build a REST api for the functionalities.
It would be great, if someone could point me in the right direction to proceed.
Thanks
Nitrogen has a very slick Comet feature built-in. It will work with the three most popular Erlang web servers, including the one you're already considering, YAWS.
Nitrogen doesn't do anything in particular about data storage. It's not one of those web frameworks that insists on managing the DB for you. You're free to use Mnesia or whatever else you like. If this bothers you, you might consider Erlyweb instead. It doesn't do Comet for you like Nitrogen does, but it's more of the manage-everything-for-me sort of web framework.
You could use:
ejabberd as the XMPP server
mnesia as the database
YAWS as the WEB server
Message Queue : you can implement that in Erlang or use an enterprise solution such as RabbitMQ
The all new Zotonic application may inspire you. It's a webapp running off mochiweb for HTTP service with webmachine for the REST API. And it's using good ol' PostgreSQL as database.
It has comet support implemented.