Michael Truog | 1 Feb 01:44
Picon
Gravatar

Re: Erlang and cloud computing

On 01/31/2012 02:16 PM, eigenfunction wrote:
> I have always been intrigued by cloudi but never had the time to take
> it for a ride. Lets say that i am building a website in erlang and
> decide to use java for (jdbc)database access or to use some NLP
> librairies. In what way can cloudi be beneficial over, say, plain old
> jinterface?

When using plain old jinterface, the JVM is used as a cnode by Erlang.  However, when using the Java CloudI
API, CloudI starts the JVM as an Erlang port while using jinterface for the communication within the JVM,
for multiple sockets, so that each socket opened for the JVM can be used by a separate Java thread.  By doing
things this way, there are a few benefits:
1) CloudI can facilitate more scalable Java source code execution with concurrent messaging done by
separate Java threads (i.e., no shared Java data or Java locks).
2) CloudI does not run the JVM as a cnode, so it does not limit the scalability of the Erlang cluster based on
the net tick time and the JVM responsiveness.  Distributed Erlang is limited to roughly 50 - 100 connected
nodes, because of the net tick time checking.  Not running the JVM as an Erlang node helps to conserve
distributed Erlang node connections so that they are only used for remote CloudI instances (on the LAN). 
This also helps to avoid extra overhead within the JVM that would otherwise be doing the net tick time
responses, because the JVM is ran on the local machine and is already managed as a separate OS process.
3) CloudI manages the fault-tolerance of the JVM execution, so that unstable Java source code can still be
ran with limited interruption if the JVM dies infrequently.

> On Jan 31, 9:36 pm, Michael Truog <mjtr...@gmail.com> wrote:
>> On 01/30/2012 07:40 AM, Yves S. Garret wrote:
>>
>>
>>
>>>    I have a curiosity question.  Is Erlang being used somehow in the field of cloud computing?  The idea of
splitting up a task and then processing it in pieces in parallel seems right up Erlang's alley.
>>>    I have looked at Windows Azure, but they mostly use .NET languages, are there services where you can have
(Continue reading)

Steve Davis | 1 Feb 02:02
Picon
Gravatar

Re: Erlang and cloud computing

Another interesting related project (more focused on enterprise
scalability, not necessarily "cloud" computing) is Spring Integration.
The centerpiece of the new Spring Integration framework is RabbitMQ,
which is of course an AMQP server written entirely in Erlang/OTP.

On Jan 30, 9:40 am, "Yves S. Garret" <yoursurrogate...@gmail.com>
wrote:
> Hello,
>
>    I have a curiosity question.  Is Erlang being used somehow in the field
> of cloud computing?  The idea of splitting up a task and then processing it
> in pieces in parallel seems right up Erlang's alley.
>
>    I have looked at Windows Azure, but they mostly use .NET languages, are
> there services where you can have a cloud computing environment and use
> Erlang to do the application development?  What has been your experience if
> you have used Erlang in cloud computing?
>
> --Yves
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.orghttp://erlang.org/mailman/listinfo/erlang-questions
Steve Davis | 1 Feb 02:21
Picon
Gravatar

Re: smtp server

I have noticed that a great number of SMTP projects fail with a
whimper. In particular, I observed that the JBoss project ran an SMTP
project for a long, long time before even barely having something
reasonable, and it's still not really "production quality". While the
underlying protocol for SMTP is straightforward, I think things run
aground owing to the teams initially underestimating the number of
rfcs and protocol extensions that you are essentially *required* to
support (especially wrt authentication etc) to have a production level
server; and also the storage issues such as the user directory and
message store.

There's no reason it couldn't be done, of course, but there's a lot of
moving parts that need to come together to make it a real production
competitor to the venerable sendmail or servers like MS exchange.

As far as Erlang is concerned, it's hard to see it happening until
certain requisite libraries are mature. For instance, START_TLS is
still not "easy" in erlang owing to the long, and continuing, struggle
to get good TLS protocol support.

Assuming that does get "finished" (and there's a whole raft of crypto
work still to do), perhaps a good start towards such a goal would be
to integrate, at the very least, an LDAP client into the base
libraries...

ok before I ramble too much, I'll leave my 2c there.

regards,
/s

(Continue reading)

Richard O'Keefe | 1 Feb 04:27
Picon
Favicon

Re: XML diff

Look at
http://www.cs.umd.edu/Outreach/hsContest99/questions/node8.html
and follow the "Our Solution" link.
which refers to Stanley Selkow's paper in
Information Processing Letters, Volume 6, number 6, 1977.

There's a paper by Wuu Yang in Software Practice and
Experience,  Volume 21, issue 7, 739-755 (July 1991),
called "Identifying Syntactic Differences Between Two Programs"
which works by finding differences between their parse trees.

There's a Perl module for precisely this task at
http://search.cpan.org/~sdether/XML-Diff-0.04/Diff.pm
The documentation points to Gregory Cobena's PhD thesis
which can be found through at
http://gregory.cobena.free.fr/www/Publications/thesis.html
I haven't read that, but it has a chapter comparing several
algorithms.

Swetha | 1 Feb 08:48
Picon

Re: Stand alone TLS encryption module?

Hi Michael,
               I have a similar requirement of load testing XMPP+TLS,i have
been using Tsung non-ssl connections have been not bale to find a tool which
supports TLS.Were you able to find a solution for it ?
If yes could you please share it with me.

Thanks,
Swetha

--
View this message in context: http://erlang.2086793.n4.nabble.com/Stand-alone-TLS-encryption-module-tp2095788p4347165.html
Sent from the Erlang Questions mailing list archive at Nabble.com.
Swetha | 1 Feb 08:52
Picon

Re: Stand alone TLS encryption module?


Chandru-4 wrote
> 
> 
> Have you tried using stunnel(*) to sit in between Tsung and ejabberd?
> That way you don't have to change Tsung at all.
> 
> Chandru
> 
> Hi Chandru,
>               Have you been successful with this approach ?Could you
> please share your findings
> 
> Thanks,
> Swetha
> 
> * http://stunnel.org
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 

--
View this message in context: http://erlang.2086793.n4.nabble.com/Stand-alone-TLS-encryption-module-tp2095788p4347172.html
Sent from the Erlang Questions mailing list archive at Nabble.com.
Jakob Praher | 1 Feb 09:05

Orthogonality and Principle of least surprise Was: chained functions

Hi Erlangers,

I think people should pay attention to issues faced by experienced newcomers in exercising Erlang
programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. 

No matter that the following may be a syntactic surface issue, but designating function objects is neither
orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding
code harder.

if I can write:
     module:fun().
I should be also able to write
     F = module:fun, F().
and not having to write
     F = fun module:fun/0, F().
.

I am happy to learn why module:fun is not an expression.

Best,
Jakob

Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" <jakob <at> praher.info> schrieb: 

>  
> As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not
atoms by themselves.
> If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current
environment? 
> 
(Continue reading)

Bengt Kleberg | 1 Feb 09:14
Picon
Favicon

Re: Orthogonality and Principle of least surprise Was: chained functions

Greetings,

This is perhaps totally wrong but in my mind allowing
F = module:fun,
F().

would also mean that this is good:
F = module:fun(,
F).

Ie, "F = module:fun" is text/syntax, not semantic.

bengt

On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote:
> Hi Erlangers,
> 
> I think people should pay attention to issues faced by experienced newcomers in exercising Erlang
programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. 
> 
> No matter that the following may be a syntactic surface issue, but designating function objects is
neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes
understanding code harder.
> 
> if I can write:
>      module:fun().
> I should be also able to write
>      F = module:fun, F().
> and not having to write
>      F = fun module:fun/0, F().
(Continue reading)

eigenfunction | 1 Feb 09:25
Picon
Favicon

Simple NAT traversal

Hi everybody,
i have an erlang application running behind a nat. Now i have come to
a point where i need to know my public ip. I was thinking about
running a tiny tcp server behind the nat whose sole purpose would be
to send me my public ip. My question is this: isn't there a more
simple alternative? Heck, even if i could determine the public ip of
the NAT device without doing a "backflip" it will be enough for my
case.
Any idea?
eigenfunction | 1 Feb 09:26
Picon
Favicon

Re: Erlang and cloud computing

Thanks for the explanation. That sounds good.

On 1 Feb., 01:44, Michael Truog <mjtr...@gmail.com> wrote:
> On 01/31/2012 02:16 PM, eigenfunction wrote:
>
> > I have always been intrigued by cloudi but never had the time to take
> > it for a ride. Lets say that i am building a website in erlang and
> > decide to use java for (jdbc)database access or to use some NLP
> > librairies. In what way can cloudi be beneficial over, say, plain old
> > jinterface?
>
> When using plain old jinterface, the JVM is used as a cnode by Erlang.  However, when using the Java CloudI
API, CloudI starts the JVM as an Erlang port while using jinterface for the communication within the JVM,
for multiple sockets, so that each socket opened for the JVM can be used by a separate Java thread.  By
doing things this way, there are a few benefits:
> 1) CloudI can facilitate more scalable Java source code execution with concurrent messaging done by
separate Java threads (i.e., no shared Java data or Java locks).
> 2) CloudI does not run the JVM as a cnode, so it does not limit the scalability of the Erlang cluster based on
the net tick time and the JVM responsiveness.  Distributed Erlang is limited to roughly 50 - 100
connected nodes, because of the net tick time checking.  Not running the JVM as an Erlang node helps to
conserve distributed Erlang node connections so that they are only used for remote CloudI instances (on
the LAN).  This also helps to avoid extra overhead within the JVM that would otherwise be doing the net
tick time responses, because the JVM is ran on the local machine and is already managed as a separate OS process.
> 3) CloudI manages the fault-tolerance of the JVM execution, so that unstable Java source code can still be
ran with limited interruption if the JVM dies infrequently.
>
>
>
>
>
(Continue reading)


Gmane