Beam VM Scheduler vs OS Scheduler - erlang

Beam VM breaks the program into small, light-weight processes and has its own scheduler. How does this scheduler works alongside the underlying OS scheduler ? If these are processes, then OS will schedule them accordingly, then how does Beam VM manages the scheduling ?

The Beam VM runs typically one OS process per core, see this answer. So the VM processes are internal, and are scheduled differently.

Related

How to monitor the local Java process using jconsole

I am using jconsole to monitor Java program deployed in tomcat server. If I want to monitor it as a local process which one should I monitor either eclipse or the tomcat server?
You can use Jconsole to monitor local as well as remote java applications. Local java processes are listed as shown below
You can select the Process (or PID) to monitor from the list

Can a dropwizard application run on all operating systems on which java is supported.

Can a dropwizard application run on all operating systems on which java is supported. Is there a list of OS on which dropwizard is supported.
Drop-wizard is a java application, which runs on JVM(java virtual machine), which is supported by almost all the operating system.
So if your operating system supports JVM then it you are good to run your DW(dropwizrd) application on it.

hardware requirements for PlasticSCM server

I'm evaluating PlasticSCM on a VMWare Machine with 4GB RAM and 4Core CPU. Since I've ported our trunk into the server (about 6GB of Data), the service ran out of memory (started swapping). I've increased the the VM RAM to 6GB This is actually more than I'd like to load the host system with, since I've also got VMs for PlasticSCM Client, TeamCity Server, TeamCity Agent.
I was trying to find a spec with details on hardware requirement for running PlasticSCM server which incorporates scaling. So far, I've only found the minimum requirement (512MB RAM etc.) and the system information of your heavy load and scale test. As far as I can see, it's all about RAM. :)
Anyway is there a detailed spec with recommendations for the hardware being used?
P.S.: Of course, in case of switching to Plastic we'd run the service on a real machine instead of VM.

.net Quartz wont run in windows 2003

i scheduled a quartz scheduler in windows 2003 server. when i am working on
the system the quartz scheduler is running.
But when the system is in idle mode (i did not touch for some time the system go's to idle) in this case i scheduled a quartz scheduler Every Day at 0 30 1 * * ? * it
doesn't fire with that expression. is the expression is correct. if
not please let me know the expression. is there any security setting
for quartz scheduler in windows 2003 server and Windows 7.
But every thing works fine in windows XP
according to CronMaker your schedule should run every day at 1.30AM.
Where are you hosting your Quartz Scheduler? ASP.NET, Windows Service ?
Are you using a RAMJobStore or a AdoJobStore ?
UPDATE:
Few months ago I've developed a custom windows services which hosts Quartz.net.
I've used AdoJobStore to persists my schedules and jobs on a Sql Server database.
The services is running on a Windows 2003 Server 32Bit and I've never experienced any kind of problem so far.
Best thing to do in these situations is to configure your app to do some debugging.
I've explained here.
You can download Common.Logging.NLog from here.
In the ZIP file you can find all the assemblies you need.
If you're using Quartz.NET 1.0.3 you have to download Common.Logging 1.2.0.
There are more infos about Common Logging infrastructure here

Live application migration between two different versions of Erlang VMs

I have Erlang application running on R13 version of Erlang VM.
I want to upgrade VM to R14 without stopping the application.
How cay I do live migration of the application between
different versions of Erlang VM?
You need two things:
a) Lots and lots of planning.
b) An application that runs on several nodes.
The usual trick is to take down part of your node cluster and upgrade that to the new version. It should be able to talk to the older nodes. Then bump the older nodes when the new version of Erlang has taken over.
Erlang does not provide this kind of upgrade for free. It does make it much less painful though.
Short answer, you can not.
This is because applications compiled for the new version of the BEAM emulator (Erlang VM) would not run properly on older versions of the emulator.
Or in more details:
Upgrading an applications without stopping it can only be done using release handler. But release handler can only upgrade applications running in the VM, not the VM itself. You can still prepare a relup file but when systools:make_relup/3 notices that the new release uses a different version of the BEAM emulator it will add the instruction restart_new_emulator (Low-Level) to restart the node during the upgrade (see the description for restart_new_emulator on the page I mentioned earlier).
What you could do, however, is upgrading the Erlang VM without interrupting the service (assuming your application provides some service to an external party). But that very much depends on the architecture of your application and has no generic answer.

Resources