I'm wondering if it is possible to get JVM support for mapping large files (64 bit offset and length support), I think solaris support mmap64 in its FileChannel; does linux port also supports similar stuff?
Thanks
Ata
Related
Is there any possibility of running Orion ContextBroker on Raspberry Pi with Raspbian OS?
The requirements recommended in the Orion documentation are:
Although we haven't done yet a precise profiling on Orion Context
Broker, tests done in our development and testing environment show
that a host with 2 CPU cores and 4 GB RAM is fine to run the
ContextBroker and MongoDB server. In fact, this is a rather
conservative estimation, Orion Context Broker could run fine also in
systems with a lower resources profile. The critical resource here is
RAM memory, as MongoDB performance is related to the amount of
available RAM to map database files into memory.
Besides the board constrained resources, you will have to search about the equivalent required libraries for RaspbianOS.
There is a discussion about it here:
https://github.com/telefonicaid/fiware-orion/issues/15
We are noticing that IBM MobileFirst Server is using High Memory by Java TM Platform SE binary process, after 2 3 days of server start it reach up to 6 GB which cause the server in hang status, then only restart is the solution.
in logs we found below message:
"No buffer space available (maximum connections reached?): connect"
Enviornment: IBm Worklight Server 7.1 and java version is 1.7 64 bit on windows server 2012. hybrid Mobile application running on this server.
It seems that there might be some configuration required can any one advice ?
Lots of information missing... this can be caused by any number of reasons.
Are you in a cluster? if yes, how many servers? how much memory is available to each machine?
How many adapters do you have deployed? What is the value you gave to the serverSessionTimeout property? This for example can cause connections to stay open for a longer time, meaning the server will not "clean/remove" connections... and the more you have open, the more memory you will require.
all of these and more can contribute to how much memory you may need.
See also: http://www-01.ibm.com/support/docview.wss?uid=swg21690707
It mentions DB2, but the idea is - the more connections, the more memory you will need.
I have a Windows 7 Enterprice 64 bit and with 8GB RAM and I run a localhost with PHP, Apache and MySQL. However, Apache is (officially) still in 32-bit binary. And my system is performing at a enormously low speed... Is this a common problem or are there any tips or trics to boost my performance?
tl;dr version: It is not the 32-bit Apache that is slowing it down.
We would need more information to determine the cause of the problem but my guess is that it isn't the fact Apache is 32bit and Windows is 64bit.
The main difference between 32 and 64bit applications is that 64bit applications can access more memory directly (normally over about 3.5GB).
Apache itself is not particularly slow, it is all the modules you load with it (PHP, Python, mod_rewrite, etc).
It is most likely one (or more) of the following:
High Requests/sec - you have a high number of requests per second
High Processing Overhead - programs/scripts are using a lot of memory/CPU
Poorly Written Programs/Scripts - programs/scripts are inefficient or leaking memory
Other Processes - other programs on your PC (including Windows itself) may be using up your memory/CPU such as MySQL
Apache 64bit builds do not generally outperform the 32bit builds by more than 5%.
The only time I've seen a major slowdown running Apache on Windows was due to anti-virus software running.
If hardware support is a must for virtualization, how can Java Virtual Machines run on machines without support for virtualization ? Or is JVM not a virtual machine ?
A JVM is not virtual in the same sense as a VirtualBox or VMWare virtual machine. It is a 'machine' that implements the Java bytecode, not a virtualized version of actual hardware.
The term-of-art 'virtual machine' was coined a very long time ago for the following scenario:
make up a computer, like Knuth's MIX.
write a computer program that implements the made-up computer.
run programs
When this virtual machine runs, it's a completely ordinary program, running completely in user mode. It needs no special help from the hardware or operating system to work reasonably well. This is especially true of the JVM, since the Java byte code does not deal with low-level hardware I/O or other things which are hard to simulate.
Later, historically, (to pick a particular instance), IBM invented VM/370. VM/370 uses the other sense of the term 'virtual machine'. In this later sense, the hardware and operating system cooperate to allow a single physical machine to host multiple virtual instances of (more or less) the same architecture, in which multiple copies of the whole operating system are written as if they are running on more or less bare hardware. Later, the X86 was designed with features to facilitate this.
So, yes, any virtual machine is making use of some physical hardware, unless you implement it with pieces of paper passed around a table (pace John Searle). But when the virtual machine bears no resemblance to the machine it is running on, then there's no need for special help from the operating system and hardware, and no need for anything as complex as VM/370, or VMware.
If hardware support is a must for virtualization, ...
Let me stop you right there :-)
There is a difference in concept between the JVM (software virtualization) and (for example) a VMWare VM (hardware-assisted virtualization).
The JVM (and other software-based VMMs such as the ones that allow to to emulate x86 on Solaris hardware - I think Bochs and possibly DosBox fall into this category) runs like any other application, using the operating system to gain access to the hardware, or emulating its own hardware purely in software.
VMWare, and the other VMMs optimised for speed, rely on hardware support. In other words, they run on the hardware as if they have full access to the hardware and, only when they try to do something they're not supposed to does the OS captures that attempt and fake it.
That's why VMWare runs so much faster than the software-only emulators. It's because, for the vast majority of the time, it's actually running on the real hardware.
The JVM is a virtual machine, but it doesn't require any additional support from the Operating System. Instead of virtualising instructions for a particular CPU it executes java bytecode.
The JVM is a virtual machine for running Java, in other words it emulates a machine which would be capable of running java. It is a confusing choice of names, but it comes from the general meaning of "machine" not from the more common Virtual Machine meaning.
The JVM, like a regular VM emulates the execution of instructions, but in the case of the JVM the instructions being emulated are Java Instructions, and in the case of a VM they are Hardware Instructions as would be executed by an OS running on the same hardware.
Yes the JVM does access hardware, however this is why you install a MAC or WINDOWS JVM since the instructions are translated by the JVM and acted upon depending on the installation of the JVM, for example, open file dialog on mac opens the mac dialog and windows JVM opens the windows dialog.
So its not being virtualized by the system, but the bytecode is being virtualized by the JVM you installed. It's basically like an application that reads something(bytecode) and does something(access hardware, or other stuff).
It should be noted that nothing stipulates that a JVM does not (have to) have HW virtualization access. There are notable exceptions, but to which the answered poster alluded, few CPs exist that run Java bytecode natively. Maybe someday a Java bytecode HAL or TIMI will be commonplace to put the JVM into the same class as the formalized HW virtualization?
With Mac OS X Server's included (or freely available) tools, a background in Objective-C and some rusty familiarity with scripting languages...how might one go about "easily" employing RESTful JSON services under Mac OS X Server?
This is mostly for prototyping so simplicity and GUI tools are appealing though not at the expense of a robust foundation.
Edit: Tickling this to see if anything's changed with Snow Leopard
Consider using simply Apache + PHP. Stable, fast, tons of knowledge and examples out there. And you may already have it running on your server.
PHP has a c'ish syntax and is easy to pick up.
See this for help in getting it running: http://foundationphp.com/tutorials/php_leopard.php
It really depends on your benchmark for "simple". With OS X Server, you have a lot of choices:
Use WebObjects, if you want to leverage your skills with Objective-C (or even Java, for that matter, if you know Java).
Use PHP... Apache and PHP are built in.
Use Python and Django/TurboGears/Twisted/Plone/WSGI/ModPython.
Use Ruby and Rails.
Use Perl and CGI... or any language and CGI, for that matter.
Use Java and Tomcat.
Use Java and Tomcat + JBoss.
It's both a blessing and a curse, in your case, that OS X Server supports almost anything. Heck, you could almost even patch CGI to AppleScript if you wanted to (aside: I'm sure we both just cringed at that :-) ). There are a lot of built-in, free, options with OS X (Client) and OS X (Server).
PHP may seem your easiest choice for the default install of Apache and its configuration, but Ruby/Rails or Python are almost as readily available out-of-the-box.