[erlang-questions] 回复:erlang-questions Digest, Vol 218, Issue 8
kgd130kgd
kgd130kgd@REDACTED
Sat May 23 15:31:51 CEST 2015
i use redhat6.5 make install ejabberd15.2(github version) report error like this.
i not change anything code
-c -m 644 deps/*/lib/*/ebin/*.app //lib/ejabberd/ebin
/usr/bin/install: 无法获取"deps/*/lib/*/ebin/*.app" 的文件状态(stat): 没有那个文件或目录
make: [install] 错误 1 (忽略)
/usr/bin/install -c -m 644 deps/*/lib/*/ebin/*.beam //lib/ejabberd/ebin
/usr/bin/install: 无法获取"deps/*/lib/*/ebin/*.beam" 的文件状态(stat): 没有那个文件或目录
At 2015-05-23 18:00:00, "" <erlang-questions-request@REDACTED> wrote:
>Send erlang-questions mailing list submissions to
> erlang-questions@REDACTED
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://erlang.org/mailman/listinfo/erlang-questions
>or, via email, send a message with subject or body 'help' to
> erlang-questions-request@REDACTED
>
>You can reach the person managing the list at
> erlang-questions-owner@REDACTED
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of erlang-questions digest..."
>
>
>Today's Topics:
>
> 1. Re: Trying to understand the performance impact of
> binary:split/3 (Jos? Valim)
> 2. Re: Why have a supervisor behaviour? (Christopher Phillips)
> 3. Re: Why have a supervisor behaviour? (Roger Lipscombe)
> 4. Re: Why have a supervisor behaviour? (Fred Hebert)
> 5. Re: Why have a supervisor behaviour? (Roger Lipscombe)
> 6. Re: SO_REUSEPORT with UDP (Max Lapshin)
> 7. Mnesia doesn't report insertion errors when underlying DETS
> file is full? (Kenneth Lakin)
> 8. Re: Mnesia doesn't report insertion errors when underlying
> DETS file is full? (Ulf Wiger)
> 9. Re: Mnesia doesn't report insertion errors when underlying
> DETS file is full? (Ulf Wiger)
> 10. Re: Mnesia doesn't report insertion errors when underlying
> DETS file is full? (?ric Pailleau)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 22 May 2015 12:41:30 +0200
>From: Jos? Valim <jose.valim@REDACTED>
>To: Jay Nelson <jay@REDACTED>
>Cc: erlang-questions <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Trying to understand the performance
> impact of binary:split/3
>Message-ID:
> <CAGnRm4J-8wA1hOhZZO92iVwbLURWpVPHw8V=AMx8S3n36OEteA@REDACTED>
>Content-Type: text/plain; charset="utf-8"
>
>Thanks for the fantastic reply Jay, I will look into this stuff carefully.
>
>
>
>*Jos? Valim*
>www.plataformatec.com.br
>Skype: jv.ptec
>Founder and Lead Developer
>
>On Thu, May 21, 2015 at 9:56 PM, Jay Nelson <jay@REDACTED> wrote:
>
>> Jose wrote:
>>
>> > I wonder how fast it would be if binary:split/3 was written as a BIF.
>>
>> I wrote a BIF in 2005 for manipulating binaries. It was documented in
>> an ICFP presentation and ACM paper. You can read about it, the
>> erlang code, and more importantly the actual BIF code at my website
>> http://duomark.com/erlang/index.html listed under the title
>> ?A Stream Library Using Erlang Binaries?. There are separate links
>> for the HTML Briefing and Code.
>>
>> http://duomark.com/erlang/publications/acm2005.pdf
>>
>> From the abstract:
>>
>> "The new BIFs are shown to improve performance as much as 250
>> times over native erlang functions. The reduction in memory usage
>> caused by the BIFs also allows successful processing in situations
>> that crashed the runtime as application functions."
>>
>> There is a gzip tar file that you used to be able to overlay on R10B(!!)
>> to build the BIFs. But it is all contained in a single stream.c file and
>> the
>> corresponding BIF table entries are in the other parts of the erts and
>> beam directories there, so it should be easy to adapt to the current
>> release you are working with. You should be able
>> to quickly get into the source and see if it meets any of your needs.
>> It will require some modification, and there are manual loop unrolling
>> and so forth that I did for performance, but as a rough quick test of
>> whether a BIF would be helpful this might be the quickest way to get
>> started.
>>
>> If you do achieve interesting results, be sure to add reduction count
>> bumping in the BIF. This code predates the option of doing that.
>>
>> jay
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150522/00beac71/attachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Fri, 22 May 2015 08:08:43 -0400
>From: Christopher Phillips <lostcolony@REDACTED>
>To: Roger Lipscombe <roger@REDACTED>
>Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Why have a supervisor behaviour?
>Message-ID:
> <CAM2vM6XfiT0c-+KFdTogu5J2MWnfXbWfZOHGKHQW-1MbdgzSZg@REDACTED>
>Content-Type: text/plain; charset="utf-8"
>
>>
>>
>> Message: 17
>> Date: Thu, 21 May 2015 16:32:40 -0400
>> From: Fred Hebert <mononcqc@REDACTED>
>> To: Roger Lipscombe <roger@REDACTED>
>> Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
>> Subject: Re: [erlang-questions] Why have a supervisor behaviour?
>> Message-ID: <20150521203238.GA52846@REDACTED>
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>> On 05/21, Roger Lipscombe wrote:
>> >I need delayed _restart_. Is this what Jesper refers to when he talks
>> >about "a delay_manager"? Such that init queries that and then
>> >might/might not delay?
>>
>> That's a classic question, and one I started answering differently.
>> Requiring a timeout in your supervisor rebooting function means that you
>> are letting things crash or restart for the wrong reason.
>>
>> The thing is, it's all about the guarantees[1]. In a nutshell, a
>> supervisor should exit on any error, and ideally bring you back to a
>> known, stable state.
>>
>> So of course all expected or unexpected errors should be able to bring
>> you back to that state properly, specifically transient errors.
>>
>> But the distinction is that because supervisors boot synchronously for
>> all apps, they also represent a chain of dependencies of what should be
>> available to all processes started *after* them.
>>
>> That's why failure modes such as 'one for all' or 'rest for one' exist.
>> They allow you to specify that the processes there are related to each
>> other in ways that their death violates some guarantee of invariant in
>> the system and that the only good way to restart is by refreshing all of
>> them.
>>
>> In a nutshell, if you expect disconnections or event that require a
>> backoff to happen frequently enough they are to be expected by the
>> processes depending on yours, then that connection or that event is not
>> a thing that should take place in your process' init function. Otherwise
>> you're indirectly stating that without this thing working, the system
>> should just not boot.
>>
>> See the example in [2] for an idea of how to respect this. This does not
>> change the code in any major way, but moves function calls around to
>> properly respect these semantics.
>>
>> My position is that this isn't a problem with supervisors' interface,
>> but in how they are being use and what they mean for your system. I know
>> this is not the most helpful response, but oh well.
>>
>>
>> [1]: http://ferd.ca/it-s-about-the-guarantees.html
>> [2]: http://www.erlang-in-anger.com, section 2.2.3
>>
>>
>> I wanted to add, every time I've seen this pattern brought up (a
>supervisor with a delayed restart), it's been due to something on the
>network has become unavailable, or overloaded to where it can't respond in
>a reasonable amount of time, that sort of thing, and the developers
>involved were seeing restart limits being hit and the system coming down,
>even though there was every reason to expect the resource to become
>available again, in time.
>
>If that's the case for you, those types of issues would likely be better
>addressed using a circuit breaker or similar[1] than a custom supervisor,
>for the reasons Fred mentions.
>
>In general, having this thing be unavailable is either due to bad internal
>state (in which case a supervisor can help you), or something external to
>your program (in which case the supervisor can't), and in the latter case
>you should be thinking about how the system should behave when it's
>unavailable (since it would be unavailable even with a delayed supervisor
>in any case). Making it a clean response that means "this resource is not
>available" allows you to address it in a well defined way, rather than
>having a child process that may or may not be there being called from
>elsewhere in your system.
>
>[1]: https://github.com/jlouis/fuse
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150522/2715f7bd/attachment-0001.html>
>
>------------------------------
>
>Message: 3
>Date: Fri, 22 May 2015 14:51:38 +0100
>From: Roger Lipscombe <roger@REDACTED>
>To: Fred Hebert <mononcqc@REDACTED>
>Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Why have a supervisor behaviour?
>Message-ID:
> <CAJgnQd9KF00P7T-_ut2ZXBB1imchOSJ-R1WxtEvUJ6k2233AGQ@REDACTED>
>Content-Type: text/plain; charset=UTF-8
>
>On 21 May 2015 at 21:32, Fred Hebert <mononcqc@REDACTED> wrote:
>> [...a bunch of useful stuff, but most importantly this next bit...]
>> My position is that this isn't a problem with supervisors' interface, but in
>> how they are being use and what they mean for your system. I know this is
>> not the most helpful response, but oh well.
>
>It turns out that I probably don't need a supervisor at all, then.
>
>Currently I have:
>
>- A supervisor, which supervises:
>- A collection of host processes, each of which owns:
>- An instance of a Squirrel VM [1] implemented in a C++ NIF.
>- When the Squirrel VM wishes to communicate with its host process, it
>sends it a message.
>- For some of those messages (divide by zero exception, syntax error,
>etc.), my host process responds via
> handle_info({exception, Whatever}, State) -> {stop, {shutdown,
>Whatever}, State}.
>- This causes the supervisor to restart the host, which fires up a
>fresh instance of the Squirrel VM.
>
>Because the Squirrel VM is running arbitrary code, it can get itself
>into a state where that code constantly crashes, so the host kills
>itself, and the supervisor restarts it constantly. My existing custom
>supervisor doesn't handle restart intensity, for precisely this
>reason. If this happens really quickly, it can lead to bad effects
>downstream (log spamming, etc.). Hence the business requirement to
>delay the restart to give the rest of the system a breather.
>
>It seems, however, that I *don't* really want a supervisor to handle
>restarting the Squirrel VM; it looks like the host should do it, and I
>might be able to remove my custom supervisor in favour of a standard
>'simple_one_for_one' supervisor to handle crashes in the host process.
>Not sure about that last -- I don't want one process hitting max
>restart intensity to bring down the other host processes.
>
>[1] http://www.squirrel-lang.org/
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 22 May 2015 10:19:12 -0400
>From: Fred Hebert <mononcqc@REDACTED>
>To: Roger Lipscombe <roger@REDACTED>
>Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Why have a supervisor behaviour?
>Message-ID: <20150522141911.GC52846@REDACTED>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>On 05/22, Roger Lipscombe wrote:
>>It turns out that I probably don't need a supervisor at all, then.
>>
>> [project description]
>>
>>It seems, however, that I *don't* really want a supervisor to handle
>>restarting the Squirrel VM; it looks like the host should do it, and I
>>might be able to remove my custom supervisor in favour of a standard
>>'simple_one_for_one' supervisor to handle crashes in the host process.
>>Not sure about that last -- I don't want one process hitting max
>>restart intensity to bring down the other host processes.
>>
>
>Ah that's interesting. To reason about this, one question to ask is:
>what is it that your system guarantees to its subsequent processes. So
>if you have some form of front-end or client handling the order of
>spawning and restarting a VM (who do you do it on behalf of?), there's
>likely a restricted set of operations you provide, right?
>
>Something like:
>
>- Run task
>- Interrupt task
>- Get task status or state report
>- Has the task completed?
>
>Or possibly, if you're going event-based, the following events are to be
>expected:
>
>- Task accepted
>- VM booted
>- VM failed
>- Task aborted
>- Task completion
>
>Those are probably things you expect to provide and should work fine,
>because those are the kinds of failures you do expect all the time from
>the Squirrel VM itself. Furthermore, it's possible you'd eventually add
>in a backpressure mechanism ("only 10 VMs can run at a time for a user")
>or something like that. This means what you might want is the host
>process to always be able to provide that information, and isolate your
>user from the VM process' fickle behaviour.
>
>So what does this tell us? What you guarantee when the supervision tree
>is booted is therefore:
>
>- I can contact the system to know if I can host a VM and run it
>- Once I am given a process, there's a manager (the host process) I can
> talk to or expect to get information from.
>
>There is no guarantee about the Squirrel VM being up and running and
>available; there's a good likelihood it's gonna be there, but in
>reality, it can go terribly bad and we just can't pretend it's not gonna
>take place.
>
>This means that these two types of processes are those you want to be
>ready and available as soon as 'init/1' has been executed. That a VM is
>available or not is not core functionality; what's core is that you can
>ask to get one, and know if it didn't work.
>
>To really help figure this out, simply ask "Can my system still run if X
>is not there?" If it can run without it, then your main recovery
>mechanism should probably not be the supervisor through failed `init/1`
>calls; it's a thing that likely becomes your responsibility as a
>developer because it's a common event. It might need to move to
>`handle_info/2`; If the system can't run without it, encode it in the
>`init/1` function. It's a guarantee you have to make.
>
>You'll find out that for some database connections, it's true. For some
>it's not and the DB *needs* to be there for the system to make sense.
>The supervisors then let you encode these requirements in your program
>structure, and their boot and shutdown sequences. Same for anything you
>may depend on.
>
>Does this make sense?
>
>Then to pick the exact supervision strategy and error handling
>mechanism, you can ask yourself what do you do when the host process
>dies. Can a new one take its place seemlessly? If not, then it's
>possible the error needs to bubble up (through a monitor or some
>message) to the caller so *they* decide whether to give up or try again.
>If you can make it transparently or it's a best effort mechanism, then
>yeah, just restarting the worker is enough.
>
>"Let it crash" is a fun fun way to get going and to grow a system, but
>when it has reached some level of growth, we can't avoid starting to
>really reason about how we want things to fail; It lets us slowly
>discover the properties we want to expose to our users, and after a few
>solid crashes, it's entirely fine to reorganize a few bits of code to
>reflect the real world and its constraints.
>
>What's great is that we've goot all the building blocks and tools to
>reason about it and implement the solution properly.
>
>Regards,
>Fred.
>
>
>------------------------------
>
>Message: 5
>Date: Fri, 22 May 2015 16:02:43 +0100
>From: Roger Lipscombe <roger@REDACTED>
>To: Fred Hebert <mononcqc@REDACTED>
>Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Why have a supervisor behaviour?
>Message-ID:
> <CAJgnQd8ORDGuHqu=jBqMu56C2H5P2Eh8e0oWdMcpYPuCt1rrGg@REDACTED>
>Content-Type: text/plain; charset=UTF-8
>
>On 22 May 2015 at 15:19, Fred Hebert <mononcqc@REDACTED> wrote:
>> On 05/22, Roger Lipscombe wrote:
>>>
>>> It turns out that I probably don't need a supervisor at all, then.
>>
>> Ah that's interesting. To reason about this, one question to ask is: what is
>> it that your system guarantees to its subsequent processes. So if you have
>> some form of front-end or client handling the order of spawning and
>> restarting a VM (who do you do it on behalf of?), there's likely a
>> restricted set of operations you provide, right?
>
>Yes:
>- Find (or start) a VM by ID.
>- Stop a VM, either by ID or by sending it a message.
>- Send a message to a VM. Some of these are gen_server:call, because
>either we need back-pressure, or we need a response; some are
>gen_server:cast (or Pid ! foo), because we don't.
>
>> To really help figure this out, simply ask "Can my system still run if X is
>> not there?"
>
>In this case, yes. If we get into a situation where we're consistently
>failing to start the squirrel VM, or if they're _all_ consistently
>failing, we'll spot that through metrics or another form of alerting.
>
>> Does this make sense?
>
>Yes. Absolutely. I need the squirrel_vm_manager (to give it a name) to
>be up, so that I can find_or_start and stop the VMs. Whether a
>particular VM is up or not is not a problem for *my* application as a
>whole.
>
>Thanks,
>Roger.
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 22 May 2015 20:16:34 +0300
>From: Max Lapshin <max.lapshin@REDACTED>
>To: Rad Gruchalski <radek@REDACTED>
>Cc: erlang questions <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] SO_REUSEPORT with UDP
>Message-ID:
> <CAMxVRxCd1vG=pxE4Dgq0aO3-dCRbafuf2NcPwCYebq003yyBLw@REDACTED>
>Content-Type: text/plain; charset="utf-8"
>
>Wow!
>
>Thanks for this thing!
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150522/db228749/attachment-0001.html>
>
>------------------------------
>
>Message: 7
>Date: Fri, 22 May 2015 22:42:02 -0700
>From: Kenneth Lakin <kennethlakin@REDACTED>
>To: erlang-questions@REDACTED
>Subject: [erlang-questions] Mnesia doesn't report insertion errors
> when underlying DETS file is full?
>Message-ID: <5560132A.4040107@REDACTED>
>Content-Type: text/plain; charset="utf-8"
>
>Hi, all. Here's hoping that I'm just misunderstanding how things work.
>I've done some searching, but it doesn't seem that anyone has asked this
>question on the list before.
>
>I'm testing with Erlang 17.3 (erts 6.2) on AMD64 Kubuntu 15.04.
>
>I wrote a little test program that uses mnesia:write/1 inside of a
>mnesia:transaction/1 to write a single integer into a Mnesia
>disc_only_copies table. Once the table grows to ~2,097,000 bytes -give
>or take-, the the on-disk table file stops growing, and mnesia:info/0
>reports that the number of records contained in the table remains constant.
>
>It's obvious that *something* is wrong, as attempts to use mnesia:first
>or mnesia:last return {aborted, {badarg, [table]}}. However, the write
>operations wrapped in mnesia:transaction keep returning {atomic,
>Result}, and comparison between a couple of calls of mnesia:info reveals
>that transactions continue to be committed and logged to disk (even
>though no new data *sticks around* on disk). I also tested this with
>mnesia:activity/2. When the DETS table hits 2GB, mnesia:activity keeps
>on trucking: it doesn't throw or exit when called with either
>transaction, or async_dirty.
>
>I would have expected mnesia:transaction to return {aborted, table_full}
>or something, rather than lying that my data was committed. Is this an
>unreasonable expectation? Did the Ubuntu or Debian folks mispackage
>Erlang in some way? Is this an oversight on the part of the OTP folks?
>
>For the curious, my program is at the end of this message. (Run it with
>test/0.)
>
>Thanks,
>-Kenneth Lakin
>%%%%%
>-module(test).
>-compile(export_all).
>-record(rec, {key, val}).
>
>test() ->
> %Default to signed intmax iterations.
> test(math:pow(2, 32)/2).
>test(Iters) ->
> mnesia:create_schema([node()]),
> mnesia:start(),
> mnesia:wait_for_tables([test], timer:seconds(30)),
> mnesia:clear_table(test),
> mnesia:create_table(test, [{attributes, record_info(fields, rec)},
> {type, bag},
> {disc_only_copies, [node()]}
> ]),
> insertData(Iters).
>
>insertData(Iters) ->
> insertData(0, Iters).
>insertData(Step, Iters) when Iters == Step ->
> ok;
>insertData(Step, Iters) ->
> F=fun() -> mnesia:write({test, Step, 0}) end,
> %This doesn't seem to throw or exit when
> %inserts fail. Trying mnesia:transaction.
> %mnesia:activity(transaction, F),
> {atomic, _} = mnesia:transaction(F),
> insertData(Step+1, Iters).
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 819 bytes
>Desc: OpenPGP digital signature
>URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150522/5ce397bd/attachment-0001.bin>
>
>------------------------------
>
>Message: 8
>Date: Sat, 23 May 2015 10:20:21 +0200
>From: Ulf Wiger <ulf@REDACTED>
>To: Kenneth Lakin <kennethlakin@REDACTED>
>Cc: erlang questions <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Mnesia doesn't report insertion errors
> when underlying DETS file is full?
>Message-ID: <730EBF82-9E07-4CBD-A087-A580A2DF18C9@REDACTED>
>Content-Type: text/plain; charset=utf-8
>
>
>> On 23 May 2015, at 07:42, Kenneth Lakin <kennethlakin@REDACTED> wrote:
>>
>> When the DETS table hits 2GB, mnesia:activity keeps
>> on trucking: it doesn't throw or exit when called with either
>> transaction, or async_dirty.
>>
>> I would have expected mnesia:transaction to return {aborted, table_full}
>> or something, rather than lying that my data was committed. Is this an
>> unreasonable expectation? Did the Ubuntu or Debian folks mispackage
>> Erlang in some way? Is this an oversight on the part of the OTP folks?
>
>This is a known problem. Dets returns an error when the table is full, but this error cannot be handled by mnesia, since it occurs *after* commit - mnesia simply expects the backend store to work.
>
>There are a number of ways to address the issue:
>
>* Use mnesia_frag to fragment disc_only tables. This is no guarantee that you will avoid the issue, but by continuously monitoring the number of objects vs number of fragments, you can minimize the risk. I consider this a pretty ugly solution, but it has been used in commercial systems. One can of course also manually ?fragment? the data, but this has the same issues, and then some.
>
>* Use disc_copies, ensure that you have a big enough box to keep all data in RAM. This has been used to great lengths by some commercial companies. The solution is not that bad, although eventually, you end up with some pretty ridiculous hardware, and pretty long startup times, since all data must be bulk-loaded into memory. One advantage is that reads and match operations become wicked fast.
>
>* Fix dets to support larger data sets. Richard Carlsson once wrote a 64-bit dets version, but it has not been adopted by OTP. One could argue that the underlying dets design is unsuitable for very large data sets, e.g. due to its recovery semantics.
>
>* Use an alternative backend. This has been done a few times, e.g. with ?mnesiaex? [1], but AFAIK, it is nowadays obsolete. Klarna has presented a similar approach, using the eleveldb backend [2], but has not (unless I missed it) made any recent announcement regarding status or availability of this solution.
>
>* Use another database solution. Many projects do this. You will forfeit some of the unique characteristics of mnesia - in particular, the extremely close integration with the runtime environment - but obviously gain other things.
>
>BR,
>Ulf W
>
>[1] https://www.openhub.net/p/mnesiaex
>[2] https://erlangcentral.org/mnesia-backend-plugin-framework-and-a-leveldb-based-plugin/#.VWA08FmeDGc
>
>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
>http://feuerlabs.com
>
>
>
>
>
>------------------------------
>
>Message: 9
>Date: Sat, 23 May 2015 10:30:31 +0200
>From: Ulf Wiger <ulf@REDACTED>
>To: Kenneth Lakin <kennethlakin@REDACTED>
>Cc: erlang questions <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Mnesia doesn't report insertion errors
> when underlying DETS file is full?
>Message-ID: <ED5EB689-4DF7-4331-B6F1-1C5C623083A4@REDACTED>
>Content-Type: text/plain; charset=utf-8
>
>
>> On 23 May 2015, at 10:20, Ulf Wiger <ulf@REDACTED> wrote:
>>
>> * Use an alternative backend. This has been done a few times, e.g. with ?mnesiaex? [1], but AFAIK, it is nowadays obsolete. Klarna has presented a similar approach, using the eleveldb backend [2], but has not (unless I missed it) made any recent announcement regarding status or availability of this solution.
>
>Ah, I did miss that Mikael Pettersson of Klarna will talk about this at the upcoming EUC:
>
>http://www.erlang-factory.com/euc2015/mikael-pettersson
>?mnesia + leveldb: liberating mnesia from the limitations of DETS
>Mnesia offers various database features, but restricts users to a few storage engines with substantial limitations. This talk describes mnesia_ext, an extension which allows arbitrary storage engines to be plugged into mnesia, and how Klarna used this to migrate parts of its database to LevelDB. We will also talk about our experiences with LevelDB, and some improvements we have made.
>
>Talk objectives:
>
>- Present mnesia_ext. Show that LevelDB is a production-grade storage engine for Erlang (with or without mnesia on top).
>
>Target audience:
>
>- Backend developers. Erlang/OTP maintainers.?
>
>BR,
>Ulf W
>
>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
>http://feuerlabs.com
>
>
>
>
>
>------------------------------
>
>Message: 10
>Date: Sat, 23 May 2015 10:38:56 +0200
>From: ?ric Pailleau <eric.pailleau@REDACTED>
>To: Ulf Wiger <ulf@REDACTED>
>Cc: Erlang Questions <erlang-questions@REDACTED>
>Subject: Re: [erlang-questions] Mnesia doesn't report insertion errors
> when underlying DETS file is full?
>Message-ID: <e4375620-6937-49d1-8cc1-610bae7f359d@REDACTED>
>Content-Type: text/plain; charset=utf-8
>
>Hi,
>Just wanted to know if mnesia subscribe on system events can raise a
>
>{mnesia_error, Format, Args}
>
>In such case ?
>
>Regards
>
>
>Le?23 mai 2015 10:30, Ulf Wiger <ulf@REDACTED> a ?crit?:
>>
>>
>> > On 23 May 2015, at 10:20, Ulf Wiger <ulf@REDACTED> wrote:
>> >
>> > * Use an alternative backend. This has been done a few times, e.g. with ?mnesiaex? [1], but AFAIK, it is nowadays obsolete. Klarna has presented a similar approach, using the eleveldb backend [2], but has not (unless I missed it) made any recent announcement regarding status or availability of this solution.
>>
>> Ah, I did miss that Mikael Pettersson of Klarna will talk about this at the upcoming EUC:
>>
>> http://www.erlang-factory.com/euc2015/mikael-pettersson
>> ?mnesia + leveldb: liberating mnesia from the limitations of DETS
>> Mnesia offers various database features, but restricts users to a few storage engines with substantial limitations. This talk describes mnesia_ext, an extension which allows arbitrary storage engines to be plugged into mnesia, and how Klarna used this to migrate parts of its database to LevelDB. We will also talk about our experiences with LevelDB, and some improvements we have made.
>>
>> Talk objectives:
>>
>> - Present mnesia_ext. Show that LevelDB is a production-grade storage engine for Erlang (with or without mnesia on top).
>>
>> Target audience:
>>
>> - Backend developers. Erlang/OTP maintainers.?
>>
>> BR,
>> Ulf W
>>
>> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
>> http://feuerlabs.com
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>------------------------------
>
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://erlang.org/mailman/listinfo/erlang-questions
>
>
>End of erlang-questions Digest, Vol 218, Issue 8
>************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150523/05c792a5/attachment.htm>
More information about the erlang-questions
mailing list