Understanding OutOfMemoryError
In Java, all objects are stored in the heap. They are allocated by the
new
operator, and discarded when the JVM determines that
no program thread can access them. Most of the time, this happens quietly,
and programmers don't give it a second thought. And then, usually a day or
so before a deadline, the program dies.
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
OutOfMemoryError
is a frustrating exception. It usually means
that you're doing something wrong: either holding onto objects too long, or
trying to process too much data at a time. Sometimes, it indicates a
problem that's out of your control, such as a third-party library that
caches strings, or an application server that doesn't clean up after deploys.
And sometimes, it has nothing to do with objects on the heap.
This article looks at the different causes of OutOfMemoryError
,
and what you can do about them. It focuses on the Sun JVM, which is the one
that I use. However, much of the material applies to any JVM implementation.
It is written based on literature available online and my own experience. I
don't work on the JVM internals, so can't speak from a position of authority.
But I have faced — and fixed — a lot of memory problems.
Garbage Collection, an Overview
I've written a detailed account of the garbage collection process elsewhere. To summarize, the mark-sweep collector starts at “garbage collection roots” and walks the entire object graph, marking every object that it touches. Objects that aren't touched are garbage, and will be collected.
Java's approach to garbage collection means that the only way you
can run out of memory is if you keep adding objects into that graph but don't
remove them. Most often, this is because you add objects to a collection
— usually a Map
— that's referenced from a static
variable. Or, less often, a collection held by a ThreadLocal
or the Runnable
of a long-lived thread.
This is very different from memory leaks in C and C++ programs. In those
languages, leaks happen when a method calls malloc()
or
new
and then returns without calling the corresponding
free()
or delete
. These are true leaks: without
using tools to match each allocation with its corresponding deallocation,
you'll never be able to recover the memory.
In Java, “leaked” memory is merely misplaced. As far as the JVM is concerned, it's all accounted for. The problem is that you, the programmer, don't know where. Fortunately, there are ways to find it.
Before diving into those techniques, there's one last thing to know about the
garbage collector: it will make a best effort to free memory before
the JVM throws OutOfMemoryError
. Which means that calling
System.gc()
will not solve your problem. You have to
find the leak and plug it yourself.
Setting the Heap Size
As pedants are fond of pointing out, the
Java Language Specification doesn't say anything about garbage collection: you could implement a JVM
that never frees memory (not that it would be terribly useful). The
Java Virtual Machine Specification notes that the heap is managed by a garbage collector, but explicitly
leaves the implementation details open. The only guarantee regarding
garbage collection is the one I stated above: the collector (if it exists)
will run before the JVM throws OutOfMemoryError
.
In practice, the Sun JVM uses a fixed-size heap that's allowed to grow as needed between minimum and maximum bounds. If you don't specify these bounds, they default to a minimum of 2Mb and a maximum of 64Mb for the “client” JVM; the “server” JVM uses defaults based on available memory. While 64Mb must have seemed enormous when it became the default in 2000 (earlier, the default was 16Mb), modern applications can easily exhaust it.
Which means that you usually have to size the heap explicitly, using the
-Xms
and -Xmx
command-line parameters:
java -Xms256m -Xmx512m MyClass
There are many rules-of-thumb for setting the minimum and maximum heap sizes. Obviously, the maximum has to be high enough to hold all of the objects that the program needs. However, setting it “just large enough” is not a good idea, because that increases the workload of the garbage collector. Instead, you should plan to keep 20–25% of the heap empty for a long-running application (although your particular application may need different settings; GC tuning is an art that's beyond the scope of this article).
Surprisingly, the minimum heap size is often more important than the maximum. The garbage collector will try to preserve the current heap size, whatever it is, rather than growing the heap. This can lead to a situation where a program creates and discards a lot of objects, but never requires memory greater than the initial (minimum) heap size. The heap will stay at that size, but the garbage collector will be running constantly to keep it there. In a production environment, I think it makes sense to set the minimum and maximum bounds to the same value.
You may wonder why I bother with limiting the maximum size: after all, the operating system won't allocate physical memory unless it's actually used. Part of the answer is that the virtual address space has to hold more than just the Java heap. If you're running on a 32-bit system, a large maximum heap size may limit the number of JARs on the classpath, or the number of threads you can create.
Another reason to limit the maximum heap size is that it helps you to discover any memory leaks in your code. Development environments tend not to stress applications. If you use a huge maximum heap size during development, you may never realize that you have a memory leak until you hit production.
Watching the Garbage Collector at Work
All JVMs provide the -verbose:gc
option, which tells the
garbage collector to write a log message to the console whenever it runs:
java -verbose:gc com.kdgregory.example.memory.SimpleAllocator [GC 1201K->1127K(1984K), 0.0020460 secs] [Full GC 1127K->103K(1984K), 0.0196060 secs] [GC 1127K->1127K(1984K), 0.0006680 secs] [Full GC 1127K->103K(1984K), 0.0180800 secs] [GC 1127K->1127K(1984K), 0.0001970 secs] ...
The Sun JVMs provide two additional options that show you the breakdown by generation, as well as the time that collection started:
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps com.kdgregory.example.memory.SimpleAllocator 0.095: [GC 0.095: [DefNew: 177K->64K(576K), 0.0020030 secs]0.097: [Tenured: 1063K->103K(1408K), 0.0178500 secs] 1201K->103K(1984K), 0.0201140 secs] 0.117: [GC 0.118: [DefNew: 0K->0K(576K), 0.0007670 secs]0.119: [Tenured: 1127K->103K(1408K), 0.0392040 secs] 1127K->103K(1984K), 0.0405130 secs] 0.164: [GC 0.164: [DefNew: 0K->0K(576K), 0.0001990 secs]0.164: [Tenured: 1127K->103K(1408K), 0.0173230 secs] 1127K->103K(1984K), 0.0177670 secs] 0.183: [GC 0.184: [DefNew: 0K->0K(576K), 0.0003400 secs]0.184: [Tenured: 1127K->103K(1408K), 0.0332370 secs] 1127K->103K(1984K), 0.0342840 secs] ...
So what does this tell us? Well, first off that collections are happening very frequently. The first field in each line is a count of seconds since the JVM started, and we're seeing collections every few hundredths of a second. In fact, adding the start time of a collection to its execution time (shown at the end of the line), it appears that the collector is running constantly.
In a real application, this would be a problem, as the collector is taking CPU
cycles away from the program. As I noted above, this might mean a too-small
initial heap size, and the log confirms that is the case: every time the heap
reaches 1.1 Mb, it gets collected. If you see this happening, increase the
-Xms
value before making changes to your application.
There's something else that's interesting about this log: other than the first collection, no objects are being stored in the young generation (“DefNew”). This indicates that the program is allocating large arrays and nothing else — which no real-world programs should do. If I saw this in a real application, my first question would be “what are these arrays used for?”
Heap Dumps
A heap dump shows you the objects that the application is using. At its most basic, it's just a count of instances and bytes by class. You can also get dumps that show the code that allocated the memory, and compare historical counts to live counts. However, the more information that you collect, the more overhead you add to the running JVM, so some of these techniques are only applicable in a development environment.
How to get a heap dump
The -XX:+HeapDumpOnOutOfMemoryError
command-line argument is
the simplest way to generate a heap dump. As its name implies, it will
generate the dump only if the program runs out of memory, which makes it
appropriate for production use. However, because it's a post-mortem dump,
the only information it can provide is a histogram of objects. Furthermore,
it creates a binary file, and you must use the
jhat tool to examine that file (this tool is part of the JDK 1.6 distribution,
but will read files produced by JDK 1.5 JVMs).
The jmap command (available since 1.5) lets you produce a heap dump from a running JVM: either a dump file for jhat, or a simple text histogram. A histogram is a good first line of analysis, particularly when you run it several times over an extended period, or when you compare live object counts to historical allocation counts.
At the far end of the scale, both in terms of information and overhead, are profilers. Profilers use the JVM's debugging interface to collect detailed information about object allocations, including line of code and the call stack. This can be incredibly useful: rather than just knowing that you've allocated a gigabyte of arrays, you can see that you've allocated 950 MB in one place, and can ignore the others. Of course, that information comes at a cost, both in terms of CPU consumption and memory to store the raw data. You won't be allowed to run a profiler in a production environment.
Heap dump analysis: live objects
The definition of a Java memory leak is that you allocate objects and don't clear all references to them, meaning that the garbage collector can't reclaim them. A heap histogram is an easy way to start looking for such leaks: it shows you not only the objects that are in your heap, but also the amount of memory they consume. The main drawback to a simple histogram is that all objects of the same class are grouped together, so you have to do some detective work to figure out where they were allocated.
Invoking jmap with the -histo
option gives you a
histogram that shows counts and memory consumption of all objects created
since the program started, including those that have already been
collected. Invoking it with -histo:live
shows the counts for
objects that are still on the heap, whether or not they are eligible for
collection.
Which means that, to get accurate counts, you need to force the garbage
collector to run before invoking jmap. If you're running the
application locally, the easiest way to do this is with
jconsole:
at the top of the “Memory” tab, there's a button labeled
“Perform GC.” If you're running in a server environment, and
have JMX beans exposed, the MemoryMXBean
(“Memory”
in the “java.lang” group) has a gc()
operation.  However, if you have a bad leak, the first major
collection is likely to be an immediate precursor to
OutOfMemoryError
.
There are two ways to use a jmap-generated histograms. The most useful technique, particularly with long-running server applications, is to invoke the “live” option several times over an extended time period, and investigate those objects whose counts keep increasing. However, depending on the server load it might take an hour or more to get good information.
A quicker approach is to compare the live objects to the total. Those objects where the live count is a significant fraction of the total are possible leaks. Here's an example that shows the top dozen entries (out of nearly 2,500) for a repository manager that's been serving 100+ users for several weeks. This program does not, as far as I know, have a memory leak, but its normal operation results in heap dumps similar to programs that do.
~, 510> jmap -histo 7626 | more num #instances #bytes class name ---------------------------------------------- 1:<PHONE_NUMBER>0816 [C 2: 84847 18748496 [I 3: 69678 15370640 [Ljava.util.HashMap$Entry; 4:<PHONE_NUMBER>6040 java.lang.String 5: 30508 13137904 [B 6:<PHONE_NUMBER>1928 java.lang.ThreadLocal$ThreadLocalMap$Entry 7: 63450 8789976 <constMethodKlass> 8:<PHONE_NUMBER>384 java.lang.ref.WeakReference 9: 43675 7651848 [Ljava.lang.Object; 10: 63450 7621520 <methodKlass> 11: 6729 7040104 <constantPoolKlass> 12:<PHONE_NUMBER>008 java.util.HashMap$Entry ~, 511> jmap -histo:live 7626 | more num #instances #bytes class name ---------------------------------------------- 1:<PHONE_NUMBER>2400 [C 2: 22804 12168040 [I 3: 15673 10506504 [Ljava.util.HashMap$Entry; 4: 17959 9848496 [B 5: 63208 8766744 <constMethodKlass> 6:<PHONE_NUMBER>120 java.lang.String 7: 63208 7592480 <methodKlass> 8: 6608 6920072 <constantPoolKlass> 9: 93830 5254480 java.lang.ThreadLocal$ThreadLocalMap$Entry 10:<PHONE_NUMBER>144 java.lang.ref.WeakReference 11: 93462 5135952 <symbolKlass> 12: 6608 4880592 <instanceKlassKlass>
When looking for a memory leak, start with the objects the consume the most
memory. That sounds obvious, but sometimes they aren't the source
of the leak. Still, it's the best place to start, and in this case, the most
memory is consumed by char[]
instances (although the total here
is 60Mb, hardly a problem). What is worrying is that the “live”
count is almost two thirds of the “ever allocated” count.
A normal program allocates objects and then releases them; if it holds onto objects for a long time, that's a possible leak. But having said that, the amount of “churn” that a particular program experiences depends on what the program is doing. Character arrays are almost always associated with strings, and some programs simply have a lot of strings that they hold for the life of the program. JSP-based app-servers, for example, define string literals for each block of HTML in the JSP. This particular program does serve HTML, but its need to hold strings is not so clear-cut: it serves directory listings, not a lot of static text. If I was running out of memory, I'd try to find out where those strings were being allocated and why they weren't discarded.
Another area for concern are the byte arrays (“[B
”).
There are a lot of classes in the JDK that use them (for example,
BufferedInputStream
), but it's rare to see them in application
code. Usually they're used as buffers, but buffers should be short-lived.
Here we see that more than half of the byte arrays ever allocated are still
considered live objects. That's worrisome, and it highlights one of the
problems with a simple histogram: all of the objects for a single class are
grouped together. For application objects, this isn't necessarily a problem,
because they're typically allocated in one section of the program. But byte
arrays are allocated everywhere, and most of those allocations are hidden
within a library. Should we search for code that calls new byte[]
,
or code that calls new ByteArrayOutputStream()
?
Heap dump analysis: associating cause and effect
To find the ultimate cause of your leak, counts of bytes by class may not be enough. Instead, you have to associate the objects that are being leaked with the objects that your program is allocating. One way to do that is to look more closely at instance counts, in order to associate objects that are allocated together. Here's an (anonymized) excerpt of a heap dump from a program that's suffering memory problems:
num #instances #bytes class name ---------------------------------------------- 1: 1362278 140032936 [Ljava.lang.Object; 2: 12624 135469922 [B ... 5:<PHONE_NUMBER>7248 com.example.ItemDetails ... 9: 1360742 21771872 java.util.ArrayList ... 41: 6254 200128 java.net.DatagramPacket
If you just looked at the top lines of this heap dump, you might start a
fruitless search for code that allocated Object[]
and
byte[]
. The actual culprits were ItemDetails
and DatagramPacket
: the former allocated multiple
ArrayList
instances, each of which in turn allocated an
Object[]
, while the latter uses byte[]
to hold
data retrieved from the network.
The first problem, allocating too-large arrays, wasn't actually a leak. The
default ArrayList
constructor allocates an array with ten
elements, and the program was only using one or two; that's 62 bytes wasted
per instance on a 64-bit JVM. A smarter design for the class would use a
List
only when one was needed, saving an additional 48 bytes
per instance. Changes like that take effort, however, and adding memory is
often cheaper.
The datagram leak was more troubling (as well as harder to fix): it indicated that received data was not being processed quickly enough.
In order to trace such chains of cause and effect, you need to know how
your application uses objects. Not many programs allocate an Object[]
:
if they use arrays at all, they'll normally use a typed array.
ArrayList
, on the other hand, uses object arrays internally.
But knowing that the memory is consumed by ArrayList
instances
isn't enough. You need to move one step up the chain, to find the objects
that hold those lists.
One way to do this is to look for correlated instance counts. In the example
above, the relationship of byte[]
to DatagramPacket
is obvious: one is almost exactly double the other. The relationship between
ArrayList
and ItemDetails
, however, isn't immediately
obvious (in fact, each ItemDetails
instance held several lists).
The trick in this case is to focus on any other class that has high instance
counts. We have a million ArrayList
instances; either they're
spread out between different classes or concentrated in a few. Regardless, a
million references is hard to hide. Even if there were a dozen classes that
held an ArrayList
, those classes would still have 100,000
instances apiece.
Tracing such chains from a histogram is a lot of work. Fortunately, jmap isn't limited to histograms, it will also produce browsable heap dumps.
Heap dump analysis: following reference chains
Browsing a heap dump is a two-step process: first, you invoke jmap
with the -dump
option, then you invoke jhat on the
resulting file. If you need to go down this route, however, make sure that
you have plenty of memory available: a dump file can easily be hundreds of
megabytes, and jhat may need several gigabytes to process that file
(I have occasionally resorted to Amazon EC2 quad-extra-large instances to be
able to browse a heap dump).
tmp, 517> jmap -dump:live,file=heapdump.06180803 7626 Dumping heap to /home/kgregory/tmp/heapdump.06180803 ... Heap dump file created tmp, 518> jhat -J-Xmx8192m heapdump.06180803 Reading from heapdump.06180803... Dump file created Sat Jun 18 08:04:22 EDT 2011 Snapshot read, resolving... Resolving 335643 objects... Chasing references, expect 67 dots................................................................... Eliminating duplicate references................................................................... Snapshot resolved. Started HTTP server on port 7000 Server is ready.
The default URL gives you a listing of all classes loaded in the system,
which I rarely find useful. Instead, I start at
http://localhost:7000/histo/
, which is a histogram view that's
sortable by instance count or total bytes (click on the image at right
to see a full-size version).
Each of the class names in this histogram is a link, that takes you to a details page for that class. There you'll see the class' position in the class hierarchy, its member variables, and a link for every reference to an instance of the class. I don't find this page terribly useful either, and the list of references will spike your browser's memory usage.
For tracking down memory problems, the most useful page is the
reference summary.
This page has two tables: referrers (incoming) and referees (outgoing), both
of which are pre-sorted by reference count. Clicking on a classname takes you
to the reference summary for that class. Using the ArrayList
example from the previous section, it's a matter of six clicks to follow the
chain from [Ljava.lang.Object;
to com.example.ItemDetails
.
You can get to the reference summary page from the class details page. But I
find it easier to construct the link directly: take the class link from the
histogram page (eg: http://localhost:7000/class/0xa5408348
) and
replace “class” by “refsByType” (eg:
http://localhost:7000/refsByType/0xa5408228
).
Heap dump analysis: allocation sites
Most of the time, knowing what objects are consuming memory is sufficient to figure out why they're being leaked. You can use jhat to find all references to those objects, and chances are good that you'll see the code that's holding objects too long. But sometimes that's not enough.
For example, if your code is leaking String
s, it may take you
days to walk through all the string manipulation code. To solve problems
like this, you need a heap dump that actually shows the places where memory
is allocated. Be aware, however, that this type of profiling adds extreme
overhead to your application, because the profiling agent must record every
invocation of the new
operator.
Most interactive profiles can produce this level of data, but I find the easiest way is to start the JVM with the built-in hprof agent:
java -Xrunhprof:heap=sites,depth=2 com.kdgregory.example.memory.Gobbler
hprof has a lot of options: not only can it profile memory usage
in a variety of ways, it will also track CPU consumption. You'll find a link
to a Sun technical article describing those options below. For this run, I
specified a post-mortem dump of allocated objects along with the locations
they were allocated, with a resolution of two stack frames. The output is
written to the file java.hprof.txt
, and the heap dump portion
looks like this:
SITES BEGIN (ordered by live bytes) Tue Sep 29 10:43:34 2009 percent live alloc'ed stack class rank self accum bytes objs bytes objs trace name 1 99.77% 99.77% 66497808 2059 66497808 2059 300157 byte[] 2 0.01% 99.78% 9192 1 27512 13 300158 java.lang.Object[] 3 0.01% 99.80% 8520 1 8520 1 300085 byte[] SITES END
This particular program doesn't allocate a lot of different object types, or allocate them in many different places. A normal dump is hundreds or thousands of lines long, showing each site where a particular object type was allocated. Fortunately, most problems appear in the first few lines of a dump. In this case, the thing that jumps out is the 64 Mb of live byte arrays, particularly since they average about 32k apiece.
Most programs don't need to hold onto that much data, so this is an
indication that the program is not properly extracting and summarizing
the data that it processes. You'll often see this happening with programs
that read large strings and then hold onto substrings: a little-known
implementation detail of String.substring()
is that it shares
a character array with the original string. If you read a file line-by-line,
yet only use the first five characters of each line, you'll still hold the
entire file in memory.
This dump also shows that the count of allocations for these arrays is equal to the count of live objects. This is a classic leak, and we can find the actual code by searching for the “trace” number:
TRACE 300157: com.kdgregory.example.memory.Gobbler.main(Gobbler.java:22)
Well, that was simple enough: when I go to that line in my code, I see that
I'm storing the arrays in an ArrayList
that never goes out of
scope. Sometimes, however, the stack trace has no connection to code that
you wrote:
TRACE 300085: java.util.zip.InflaterInputStream.<init>(InflaterInputStream.java:71) java.util.zip.ZipFile$2.<init>(ZipFile.java:348)
In this case, you need to increase the depth of the stack trace and rerun
your application. There's a tradeoff here: as you capture more stack frames
you increase the overhead of profiling. The default, if you don't specify a
depth
value, is 4. I find that most problems in my code can be
discovered with a depth of 2, although I have run with depths as high as 12
(on a machine that had a half gigabyte of physical memory; it was thrashing,
and the profiling run took close to an hour, but I found the problem).
One other benefit of increasing the stack depth is that the report will be more granular: you might discover that you're leaking objects from two or three places, all of which use a common method.
Heap dump analysis: locality
Generational garbage collectors work because most objects are discarded shortly after they're allocated. You can use the same principle to find memory leaks: using a debugger, set a breakpoint at the allocation site and then walk through the code. In almost all cases, you'll see it added to a long-lived collection shortly after allocation.
The Permanent Generation
In addition to the young and tenured generations of the application heap, the JVM also manages an area called the “permanent generation,” where it stores objects such as classes and string literals. Normally, you don't see the garbage collector work on the permanent generation; most of the action happens in the application heap. But despite its name, objects in the permgen aren't always there permanently. Classes loaded by an app-server classloader, for example, are cleaned up once there are no longer any references to the classloader. And in an application server doing hot deploys, this may happen very frequently … except when it doesn't:
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
Note the message: it's not referring to the application heap. You can run out of permgen space even when there's plenty of space in the application heap. Usually, it happens when you're redeploying an EAR or WAR, and simply indicates that the permgen isn't large enough to hold both the old classes and the new (the old classes are retained until all requests that used them have completed). This happens a lot when running a development app-server.
The first step to resolving permgen errors is to increase the permgen space,
which you do with the -XX:MaxPermSize
command-line argument.
The default is 64M, but 256M is usually needed for an app-server or IDE.
java -XX:MaxPermSize=256m
Sometimes, however, it's not so simple. Leaks in the permgen happen for the
same reason as leaks in the application heap: somewhere there's an object
that's holding a reference that it shouldn't. In my experience, these tend
to be references to actual Class
objects, or objects in the
java.lang.reflect
package, rather than instances of a class.
And because of the way that app-server classloaders are structured, the usual
culprit is found in the server configuration.
For example, if you're using Tomcat, you have a directory for shared JARs:
shared/lib
. If you're running several web-apps on the same server,
it makes sense to put some JARs in that directory, because their classes will
be loaded only once, and you'll reduce the overall memory footprint of the
server. However, what happens if one of those libraries has an object cache?
The answer is that, until the cache releases its reference to an application
object, that application's classes won't get unloaded. The soluton in this
case is to move the library into the WAR or EAR. But sometimes it's not so
simple: the JDKs bean
introspector caches BeanInfo
instances and is loaded by the
boot classloader. Any library using introspection will also cache those
instances, and you may not know where the real responsibility falls.
Solving permgen problems is painful. The way to start is to track class
loading and unloading with the -XX:+TraceClassLoading
and
-XX:+TraceClassUnloading
command line options, Look for the
classes that are loaded but not unloaded. If you add the
-XX:+TraceClassResolution
flag, you can see where one class
accesses another, which may help you to find who is holding onto classes
that aren't unloaded.
Here's a excerpt of output with all three options. The first line shows
MyClassLoader
being loaded from the classpath. Then, since it
extends URLClassLoader
, we see a “RESOLVE” message,
followed in turn by another resolve message as UrlClassLoader
references Class
.
[Loaded com.kdgregory.example.memory.PermgenExhaustion$MyClassLoader from file:/home/kgregory/Workspace/Website/programming/examples/bin/] RESOLVE com.kdgregory.example.memory.PermgenExhaustion$MyClassLoader java.net.URLClassLoader RESOLVE java.net.URLClassLoader java.lang.Class URLClassLoader.java:188
The information is all there, but it's usually faster just to move shared libraries into the WAR/EAR until the problem goes away.
OutOfMemoryError
When There's Still Heap Memory Available
As you saw with the permgen message, OutOfMemoryError
gets
thrown for reasons other than the application heap getting full. Here are
a few cases:
Contiguous allocation
When I was describing the generational heap, I said that objects would be allocated in the young generation, and eventually moved into the tenured generation. This isn't quite true: if your object is large enough, it will be created directly in the tenured generation. User-defined objects won't (shouldn't!) have anywhere near the number of members needed to trigger this behavior, but arrays will: with JDK 1.5, arrays larger than a half megabyte go directly into the tenured generation.
A half megabyte translates into an Object[]
containing 131,072
elements on a 32-bit JVM. Big, but within the realm of possibility for an
enterprise scale application. Particularly one that uses a HashMap
that needs to resize itself. And some applications need to work with much
larger arrays.
The problem happens when there isn't a contiguous block of memory to hold the array, even after the garbage collector compacts the heap. This is rare, and the only time you'll run into it is when you're close to the limits of heap memory anyway. Increasing the maximum heap size is the best solution, but you can also try pre-sizing your large collections.
Threads
The JavaDoc for OutOfMemoryError
indicates that it is thrown
when the garbage collector is unable to make memory available. This is
only half true: the JVM also throws OutOfMemoryError
when its
internal code receives an ENOMEM
error from the operating
system. As Unix programmers know, there are a lot of places where you get
ENOMEM
, one of which is thread creation:
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
On my 32-bit Linux box, running JDK 1.5, I can start 5,550 threads before getting this error. But there's still plenty of memory in the application heap (see this example). So what's happening?
Behind the scenes, threads are managed by the operating system, not the JVM, and thread creation can fail for any number of reasons. In my case, each thread takes about a half megabyte of virtual memory for its stack, and after 5,000 threads the 2G process memory space is used up (more on this below). Some operating systems might also impose a hard limit on the number of threads that can be created for a single process.
Again, there really isn't a solution to this problem other than changing your program. Most programs have no reason to create that many threads; they'll be spending all of their time waiting for the operating system to schedule them. But some server applications could reasonably create thousands of threads to service requests, knowing that most will be waiting for data; in this case, the solution might be NIO channels and selectors.
Direct ByteBuffers
Java has allowed applications to access memory outside of the heap (in a
limited way) since JDK 1.4, using bytebuffers. And while the ByteBuffer
object itself is
very small, the off-heap memory that it controlls may not be.
Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
There are several reasons for bytebuffer allocations to fail, which I've described in the linked article. Usually, however, it's because you've either exceeded the virtual memory space (only relevant on a 32-bit JVM) or placed a claim on all of physical memory and swap. But unless you're simply dealing with data that's too large for your machine, you run out of memory with direct buffers for the same reason that you run out of heap memory: you're holding a reference that you don't think you are. The heap analysis techniques described above can help you to find that leak.
Commit charge exceeds physical memory
As I noted earlier, the JVM is unique in that you specify the minimum and
maximum size of its heap on startup. This means that the JVM will change its
demand for virtual memory while it's running. On a memory-constrained machine,
you might be able to start multiple JVMs, even though their combined maximum
heaps exceed available physical memory and swap. The result will be an
OutOfMemoryError
even though the total size of your live objects
is less than the specified heap size.
This situation is no different from running multiple C++ programs that use
all available memory. The JVM simply tricked you into thinking you could get
away with it. The only solution is to buy more memory or run fewer programs.
There's no way to make the JVM “fail fast” in this situation; at
least on Linux, you can make a claim (via the -Xms
and
-Xmx
parameters) on far more memory than can be supported.
Looking Outside the Heap
That last situation brings up an important point: the Java heap is only part of the story. The JVM also uses memory for threads, its internal code and work space, shared libraries, direct buffers, and memory-mapped files. On a 32-bit JVM, these all have to fit into a 2GB virtual address space, which is a scarce resource (at least in server and back-end applications). On a 64-bit JVM, the virtual address space is effectively unlimited; physical memory is the scarce resource.
There aren't a lot of things that go wrong with virtual memory; the OS and JVM are pretty smart about managing it. Usually, the only reason that you'd look at a virtual memory map is to identify large chunks of memory used by direct buffers and memory-mapped files. But it's useful to know what the virtual memory map looks like, if only for personal education.
To dump the virtual memory map on Linux, you use pmap; for Windows, use VMMap (there may be other tools; I don't do much development on Windows). The following is an excerpt of the pmap output for a Tomcat server. The actual dump file is hundreds of lines long; this excerpt just shows the interesting bits.
08048000 60K r-x-- /usr/local/java/jdk-1.5/bin/java 08057000 8K rwx-- /usr/local/java/jdk-1.5/bin/java 081e5000 6268K rwx-- [ anon ] 889b0000 896K rwx-- [ anon ] 88a90000 4096K rwx-- [ anon ] 88e90000 10056K rwx-- [ anon ] 89862000 50488K rwx-- [ anon ] 8c9b0000 9216K rwx-- [ anon ] 8d2b0000 56320K rwx-- [ anon ] ... afd70000 504K rwx-- [ anon ] afdee000 12K ----- [ anon ] afdf1000 504K rwx-- [ anon ] afe6f000 12K ----- [ anon ] afe72000 504K rwx-- [ anon ] ... b0cba000 24K r-xs- /usr/local/java/netbeans-5.5/enterprise3/apache-tomcat-5.5.17/server/lib/catalina-ant-jmx.jar b0cc0000 64K r-xs- /usr/local/java/netbeans-5.5/enterprise3/apache-tomcat-5.5.17/server/lib/catalina-storeconfig.jar b0cd0000 632K r-xs- /usr/local/java/netbeans-5.5/enterprise3/apache-tomcat-5.5.17/server/lib/catalina.jar b0d6e000 164K r-xs- /usr/local/java/netbeans-5.5/enterprise3/apache-tomcat-5.5.17/server/lib/tomcat-ajp.jar b0d97000 88K r-xs- /usr/local/java/netbeans-5.5/enterprise3/apache-tomcat-5.5.17/server/lib/tomcat-http.jar ... b6ee3000 3520K r-x-- /usr/local/java/jdk-1.5/jre/lib/i386/client/libjvm.so b7253000 120K rwx-- /usr/local/java/jdk-1.5/jre/lib/i386/client/libjvm.so b7271000 4192K rwx-- [ anon ] b7689000 1356K r-x-- /lib/tls/i686/cmov/libc-2.11.1.so ...
The dump output gives you four pieces of information for each segment in the memory map: its virtual address, its size, its permissions, and its source (for segments that are loaded from a file). Of these, the most interesting in terms of resource management are the permissions flags, which indicate whether the segment is read-only (“r-”) or read-write (“rw”).
I'll start with the read-write segments. Most of these have the name
“[ anon ]
”, which is what Linux gives
to everything that isn't associated with a file. There are also a few named
read-write segments here, associated with shared libraries; I believe that
these are the per-process relocation tables for those libraries.
Since most of the writable segments have the same name, it can take a bit of detective work to figure out what you're looking at. The Java heap will be four relatively large chunks that are allocated together (two for the young generation, one for the tenured generation, and one for the permgen); their total and relative sizes will depend on the GC and heap configuration. Each Java thread requires its own stack and scratch space; these are allocated in pairs, and you'll see the same pairs repeated through the map (in this map, the pairs are 504k/12k). Everything else corresponds to direct buffers (which may belong to your code, the JDK, or a third-party library) and runtime scratch spaces (which can belong to the JVM or third-party libraries).
The main issue with read-write segments is that they add to the process'
“commit charge”: the amount of physical memory and/or swap that
is required for the process to run. The total commit charge for all of the
programs running on a machine cannot exceed the physical RAM and swap of
that machine. Modern operating systems deal with this gracefully: they
return an ENOMEM
when the program tries to allocate (older
systems preferred to crash). This results in an OutOfMemoryError
for your program, a situation that I described in the previous section.
Read-only memory segments can be shared between processes, and give the
operating system flexibility when managing physical memory: it can simply
drop read-only pages, knowing that the can be reloaded from the source as
needed. They're used for standard system libraries (eg,
libc
), the application code (libjvm
), and
memory-mapped files — including JARs from the classpath.
Memory-mapped JARs are an optimization: the JAR directory is at the end of
the file, and contains offsets to the individual entries, so you can quickly
access the entry with a “bulk get” operation. For classpath JARs
this is a big win: you don't have to scan a JarInputStream
(or
use a caching scheme) every time you need to load a class. But there's a
cost: memory-mapped files decrease the space available for the application
heap and thread stacks.
With typical library JARs this isn't an issue, becasue they tend to be small
(the JDK's rt.jar
is large at 1.6 MB). Files that contain large
resources (eg images) are another matter, although the JVM seems to be smart
about only mapping portions of the file. But the your program can
explicitly map any
JAR or ZIP. As always, with great power comes great responsibility; give
thought to why you want to memory-map the file. On a 32-bit JVM it's almost
always better to unzip the JAR's contents into a scratch directory.
Closing Comments
This section contains bits and pieces that didn't quite fit anywhere else. Most are tips from my personal experience in debugging memory problems.
Don't be misled by virtual memory statistics
There's a common complaint that Java is a “memory hog,” often
evidenced by pointing at the “VIRT” column of top or
the “Mem Usage” column on Windows Task Manager. As the last
section should have made clear, there's a lot that goes into this number,
and some of it is shared with other programs (the C library, for example).
There is also a lot of “empty” space in the virtual memory map:
if you invoke the JVM with -Xms1000m
, the virtual size will
start out over a gigabyte before you even start allocating objects.
A much better measurement is the resident set size: the number of pages of physical memory that are actually used by your program, excluding shared pages. This is the “RES” column in top (I don't think it was available in Task Manger prior to Windows 7). However, resident set isn't a very good measure of your program's actual memory usage either. The operating system will leave physical pages in a process' memory space until it needs them elsewhere, and unless your system is heavily loaded that may take a long time.
Bottom line: always diagnose Java memory problems using tools that provide
the detail needed to solve those problems. And don't jump to conclusions
until you see an actual OutOfMemoryError
.
OutOfMemoryError is often thrown close to the source
Earlier I mentioned “locality”: that memory leaks usually
happen soon after the memory is allocated. A similar observation is that
the OutOfMemoryError
is often thrown close to the leak, and
the stack trace (if it's available) can be a first step in diagnosis. The
rationale behind this observation is that, to be noticeable, a leak must
involve a lot of memory. Which means that, either due to the frequency
that allocation code is called, or the volume of memory allocated on each
pass, the leaky code will get a higher volume of failures. Not an ironclad
rule, but it works well enough that I pay attention to the stack traces.
Always suspect caches
I've mentioned caches several times in this article, and with good reason: most of the memory leaks that I've seen, in over a dozen years working with Java, are found in a class with “Cache” in its name. And I wrote a few of them. The trouble is that caches aren't easy to get right.
That said, there are a lot of good reasons to use a cache, and a few good reasons to write your own (although in most cases, an off-the-shelf cache like EHCache is a better choice). If you do choose to use a cache, make sure that you have answers to the following questions:
- What objects go into the cache?
If you limit your cache to a single object type (or inheritance tree), then it's much easier to trace cause and effect versus a generic cache that holds many different types of objects. - How many objects should be in the cache at any point in time?
Again, if you know thatProductCache
should only hold 1,000 entries, but see 10,000 instances ofProduct
in the histogram, the link between cause and effect is easier to trace. More important, if you go in with a maximum size in mind, then you can easily calculate how much memory you'll need for the cached objects. - What is the eviction policy?
Every cache should have an explicit eviction policy that controls how long objects will remain in the cache. If you don't have a policy in place, then objects may remain in the cache long after the program needs them — using memory and adding load to the garbage collector (remember: the mark phase requires time proportional to live objects). - Will I hold other long-lived references to cached objects?
Caches work best in code that's executed frequently, doesn't take a lot of time to run, but needs objects that are expensive to retrieve from source. If you create an object and need a reference to it as long as your program runs, there's no need to put that object in a cache (although a pool might be a good idea, to control the number of instances).
Pay attention to object lifetime
Objects generally fall into two classes: those that live as long as the program is running, and those that live only long enough to service a single request. Keeping the two separate and knowing which is which is the key to easy debugging: you only need to look at the objects you know are long-lived.
One way to do this is to explicitly initialize all of your long-lived objects when the program starts, whether or not they're needed right away. Another, better, approach is to use a dependency injection framework like Spring. Not only does it mean that all long-lived objects will be found in the bean configuration (never use classpath scanning!), but it's easy to find all of the places where those beans are used.
Look out for instance variables misused as method parameters
In almost all cases, the objects allocated within a method should be discarded by the end of that method (excluding return values, of course). As long as you use local variables to hold all these objects, this rule is easy to follow. However, it's tempting to use instance variables to hold method data, particularly for methods that call a lot of other methods, and thereby avoiding the need for large parameter lists.
Doing this won't necessarily create a leak. Subsequent method calls should re-assign the variables, allowing the objects to be collected. But it raises your memory requirements unnecessarily (sometimes enormously) and makes debugging more difficult (because you have unexpected objects in memory). And from a general design perspective, when I've seen code like this it has always indicated that the method really wants to be its own class.
J2EE: don't abuse the session
The session object exists to hold user-specific data between web requests;
it's a way around the stateless nature of HTTP. Far too often it ends up as
a makeshift cache. For example, an eCommerce programmer might store a
Product
object in the session, rationalizing that the user will
be browsing several pages for the same product.
This won't turn into a true leak, because the servlet container will time-out
the user's session. But it needlessly increases the memory footprint of the
application, which is just as bad (it doesn't matter what causes the
OutOfMemoryError
, the application is just as dead). And it's
hard to debug: as I noted above with mixed-content caches, there's no clear
indication of where the objects are being held.
 Tuning the garbage collector is an art, and one that I haven't
spent a lot of time doing. So I've included some references at the end of
this article.
64-bit processors and cheap RAM won't make your problems go away
This article was originally written when 32-bit processors were mainstream, and so contains a lot of caveats about how pieces of the JVM have to share a 2 Gb virtual address space. Most of those caveats will soon be obsolete: when you can go to an office supply store and spend $500 (in early 2011) for a PC with 6 gig of RAM and effectively unlimited virtual address space, there doesn't seem to be a lot gained by fussing over every last byte.
But that doesn't mean that you shouldn't pay attention to your memory footprint. Large heaps and lots of live objects can turn into a “GC timebomb,” in which the garbage collector spends an inordinate amount of time doing its job. Even with a concurrent GC, your application may be blocked waiting for memory to be freed so that it can allocate more.
Sometimes you just need more memory
As I said back at the beginning, the JVM is the only modern programming
environment that I know of that forces you to set a maximum size for your
data. Because of this, there are times when you think you have a leak but
in fact you just have to increase the heap size. The first step in resolving
a memory problem should always be increasing the available memory. If you
have an actual leak, you'll get an OutOfMemoryError
no matter
how much memory you provide.
For More Information
Sun's tuning whitepaper (JDK 1.6 edition) describes how the Sun JVM manages its heap, and how you can adjust the behavior of the garbage collector. There's also a FAQ on features of the various garbage collectors.
This document lists the Sun-only JVM configuration options. There are a number of useful diagnostic options that I haven't covered here.
This Sun technote describes the built-in “hprof” profiling tool.
The chapter on memory management from O'Reilly's System Performance Tuning, 2nd Edition gives a nice overview of how Unix manages process memory (this book is 10 years old, but the concepts haven't changed much in the last 30+ years, so it's still relevant).
My article on Java reference objects will help you manage memory so that you can avoid running out.
I've created several example programs that consume resources:
- Gobbler grabs as much memory as it can, and never lets go.
- SimpleAllocator grabs memory and then immediately releases it. Its lets you watch the GC in action.
- PermgenExhaustion creates classloader instances, and uses them to load a class. It can be difficult to follow, but will also give you an idea of how classloaders work.
- ThreadExhaustion fires up as many threads as it can. On both Linux and Windows XP, the maximum number of threads is limited by virtual memory. Other systems may impose lower limits.


What's Trending
School News
My Tasks
Things I should accomplish
| " | ||
Timetable
Class and Daily routines
| MON | TUE | WED | THU | FRI | SAT | SUN |
|---|---|---|---|---|---|---|
| Math | Phy | Math | Chem | Geo | Math | KIN |
| Chem | Math | Math | Math | Geo | Geo | KIN |
| Math | Math | Chem | Chem | Geo | Geo | Fra |
| Fra | Eng | Chem | Chem | Eng | Phy | Hist |
| Math | Rel | Phy | Phy | Math | Sport | Bio |
| Rel | Rel | Rel | Phy | Chem | Bio | Bio |


Functions | |
| static __always_inline void | board_enable_touch_adc (void) |
| Clear PR bit for default touch ADC. | |
| static __always_inline void | board_disable_touch_adc (void) |
| Disable ADC and references, then set its PR bit. |
This uses the configuration set in config-xplain.mk for the application.
| static __always_inline void board_disable_touch_adc | ( | void | ) | [static] |
Disable ADC and references, then set its PR bit.
Definition at line 79 of file touch.h.
References ADC_BFMASK, ADC_BIT, adc_read_reg, adc_write_reg, SYSCLK_ADC, sysclk_disable_module(), and SYSCLK_PORT_A.
| static __always_inline void board_enable_touch_adc | ( | void | ) | [static] |
Clear PR bit for default touch ADC.
Definition at line 67 of file touch.h.
References SYSCLK_ADC, sysclk_enable_module(), and SYSCLK_PORT_A.


--- layout: feedback title: Sebastine P - 2015-08-04 13:59:03 date: 2015-08-04 13:59:03.000000000 -05:00 categories: [] tags: [] status: publish type: feedback published: true meta: _feedback_extra_fields: a:0:{} _feedback_email: "a:2:{s:2:\"to\";a:1:{i:0;s:29:\"adam.n.england+blog@gmail.com\";}s:7:\"message\";s:1542:\"Name: Sebastine P\nEmail<EMAIL_ADDRESS>Message: Hi Adam England,\r\n\r\nHope you’re doing well!\r\n\r\nOur client is need of Mobile App Developer Firefox OS for a Long Term Project in Bridgewater, NJ. Kindly find below detailed Job Description.\r\n\r\nAssignment Details:\r\nTitle: Mobile App Developer Firefox OS\r\nLocation: Bridgewater, NJ\r\nDuration: Long Term\r\n\r\nJob Description:\r\n•\tExperience developing Apps on the Firefox OS\r\n•\tExperience in front end design using HTML5/HTML, CSS3/CSS\r\n•\tExperience with JavaScript frameworks such as jQuery and node.js required\r\n•\t3 or more years of experience with web development showing an emphasis on front end development\r\n•\tExperience with other programming languages Java/C/C++/C# required\r\n•\tHybrid/Native mobile application development for platforms like Android, iOS, Firefox OS preferred\r\n•\tExperience working with Databases\r\n•\tXML/JSON\r\n•\tSubversion (SVN), Maven\r\n•\tIDE use such as Eclipse\r\n•\tBasic understanding of TCP/IP networks\r\n•\tData Security Considerations\r\n•\tAgile Software Development Methodologies\r\n\r\nAppreciates your quick response.\r\n\r\nThanks,\r\nSebastine P\r\nCES USA Inc,\r\nEmail<EMAIL_ADDRESS>| Gtalk<EMAIL_ADDRESS>| LinkedIn\r\nPh:<PHONE_NUMBER> Ext: 764 | Mobile: +1<PHONE_NUMBER>\r\nwww.cesltd.com | CES Group | 235 Remington Blvd Suite # H Bolingbrook IL 60440\n\nTime: August 4, 2015 at 1:59 pm\nIP Address: <IP_ADDRESS>\nContact Form URL: https://adamnengland.wordpress.com/contact-me/\nSent by an unverified visitor to your site.\";}" author: excerpt: !ruby/object:Hpricot::Doc options: {} ---
Hi Adam England,
Hope you’re doing well!
Our client is need of Mobile App Developer Firefox OS for a Long Term Project in Bridgewater, NJ. Kindly find below detailed Job Description.
Assignment Details:
Title: Mobile App Developer Firefox OS
Location: Bridgewater, NJ
Duration: Long Term
Job Description:
• Experience developing Apps on the Firefox OS
• Experience in front end design using HTML5/HTML, CSS3/CSS
• Experience with JavaScript frameworks such as jQuery and node.js required
• 3 or more years of experience with web development showing an emphasis on front end development
• Experience with other programming languages Java/C/C++/C# required
• Hybrid/Native mobile application development for platforms like Android, iOS, Firefox OS preferred
• Experience working with Databases
• XML/JSON
• Subversion (SVN), Maven
• IDE use such as Eclipse
• Basic understanding of TCP/IP networks
• Data Security Considerations
• Agile Software Development Methodologies
Appreciates your quick response.
Thanks,
Sebastine P
CES USA Inc,
Email<EMAIL_ADDRESS>| Gtalk<EMAIL_ADDRESS>| LinkedIn
Ph:<PHONE_NUMBER> Ext: 764 | Mobile: +1<PHONE_NUMBER>
www.cesltd.com | CES Group | 235 Remington Blvd Suite # H Bolingbrook IL 60440
AUTHOR: Sebastine P
AUTHOR EMAIL<EMAIL_ADDRESS>AUTHOR URL:
SUBJECT: BLOG - Contact Me Submission
IP: <IP_ADDRESS>
Array
(
[1_Name] => Sebastine P
[2_Email] =><EMAIL_ADDRESS>[3_Your Message] => Hi Adam England,
Hope you’re doing well!
Our client is need of Mobile App Developer Firefox OS for a Long Term Project in Bridgewater, NJ. Kindly find below detailed Job Description.
Assignment Details:
Title: Mobile App Developer Firefox OS
Location: Bridgewater, NJ
Duration: Long Term
Job Description:
• Experience developing Apps on the Firefox OS
• Experience in front end design using HTML5/HTML, CSS3/CSS
• Experience with JavaScript frameworks such as jQuery and node.js required
• 3 or more years of experience with web development showing an emphasis on front end development
• Experience with other programming languages Java/C/C++/C# required
• Hybrid/Native mobile application development for platforms like Android, iOS, Firefox OS preferred
• Experience working with Databases
• XML/JSON
• Subversion (SVN), Maven
• IDE use such as Eclipse
• Basic understanding of TCP/IP networks
• Data Security Considerations
• Agile Software Development Methodologies
Appreciates your quick response.
Thanks,
Sebastine P
CES USA Inc,
Email<EMAIL_ADDRESS>| Gtalk<EMAIL_ADDRESS>| LinkedIn
Ph:<PHONE_NUMBER> Ext: 764 | Mobile: +1<PHONE_NUMBER>
www.cesltd.com | CES Group | 235 Remington Blvd Suite # H Bolingbrook IL 60440
)


Location of all road section
jQuery UI Draggable - Default functionality
Legend Description
Road section location


Up to 50% off
Permanent Makeup Black Friday Deal
Eyeliner
Semi permanent eyeliner, choice of winged, eye shadow effect or simple liner. Top or bottom liner. Helps enhance natural eye shape. Touch up included in price. Color will be advised by professional during consultation.
Book my free consultationLip Blush
Customized permanent lip color. Can be full lips, ombre or liner. Lasts 4 years plus with minimal fading. One month touch up included in price. Color will be advised by professional during consultation.
Book my free consultationMicroshaded Eyebrows
Customized to fit your natural facial features. This look is permanent and looks similar to makeup. Lasts 4 years plus with minimal fading. One month touch up included in price. Color will be advised by professional during consultation.
Book my free consultationReviews
***** Five out of five stars. Top Reviewer
Monica November 8, 2020 Amazing
***** Five out of five stars. Top Reviewer
Andrea October 24, 2020 Ann is very professional and does amazing work!
***** Five out of five stars. Top Reviewer
Barbara October 6, 2020 Very nice office, Ann was wonderful. Ever pleased with my eye liner and will definitely go back for other services. Barbara R.
COVID-19 Precautions
-
No mask no service
-
Stay home if unwell
-
Must sign COVID 19 consent form
-
No extra company
-
Must wash hands upon arrival
-
Temperature check


Dat is a new peer-to-peer protocol. It provides public key addressed file archives which can be synced securely and browsed on demand.
It is a decentralized protocol, that is any device can host any archive. Files in dat archive are versioned. Changes are written in an append only log.
Dat is a protocol for sharing data between computers. It's strengths are that data is hosted and distributed by many computers on the network, so that it can work
offline or with poor network quality. The original upoader can add or modify data while keeping a full history and it can handle large amounts of data.
Click here to learn more about how DAT protocol works
Dat project official website


I am excited to do so many things here!
A few restaurants I can't wait to try:
Yes, I admit I want to be a super tourist and check out these places:
- Statue of Liberty
- World Trade Center
- Empire State Building (the top)
- Central Park
A few restaurants I can't wait to try:
Yes, I admit I want to be a super tourist and check out these places:


--- layout: page title: FreeRADIUS 'man' pages subtitle: Documentation from the server subpage: true navorder: 200 hero: documentation subnav: - text: Programs link: '/radiusd/man/#programs' - text: Configuration Files link: '/radiusd/man/#files' - text: Modules link: '/radiusd/man/#modules' ---
The rlm_sql_log module does something similar, but for SQL queries. See it's man page for details.
That will cause your accounting packets to go the the backup server - and some NASes don't even switch back to the primary server when it comes back up.
The result is that accounting records are missed, and/or the administrator must jump through hoops in order to combine the different detail files from multiple servers. It also means that the session database ("radutmp", used for radwho and simultaneous use detection) gets out of sync.
We solve this issue by "relaying" packets from one server to another, so they both have the same set of accounting data.
See raddb/sites-available/buffered-sql for more information.
Similarly, you may have one database that tracks "live" sessions, and another that tracks historical accounting data. In that case, accessing the first database is fast, as it is small. Accessing the second database many be slower, as it may contain multiple gigabytes of data. In addition, writing to the first database in a timely manner is important, while data may be written to the second database with a few minutes delay, without any harm being done.
See raddb/sites-available/copy-to-home-server for more information.


public class Server<P>
extends java.lang.Object
| Modifier and Type | Class and Description |
|---|---|
private static class |
Server.RunStatus
Enumerates the possible states of the Server, that is, whether it is
running, stopped or aborted (abruptly stopped).
|
| Modifier and Type | Field and Description |
|---|---|
private java.util.concurrent.BlockingQueue<java.lang.Integer> |
actorIdQueue
The queue of actors available to perform a protocol round.
|
private Actor<P>[] |
actorPool
An array pooling all created Actor objects.
|
private CommunicationResource<P> |
communicationResource
The communications protocol implementation to be used.
|
private java.util.Map<java.lang.String,java.lang.String> |
initialAddressMap
The list of addresses for characters that is fixed for all runs of the
protocol.
|
private java.util.Map<java.lang.Long,Actor<P>> |
ongoingRuns
The map of run IDs to the objects performing the run.
|
private Part |
part
The part to be interpreted by this Server object.
|
private Server.RunStatus |
status
Current state of the server.
|
private java.lang.Thread[] |
threadPool
The pool of threads in which actors are running (one Thread, one Actor).
|
| Constructor and Description |
|---|
Server(Part part,
CommunicationResource<P> communicationResource,
java.util.function.Supplier<A> actorFactory,
int size)
Creates a new Server object to interpret the protocol Part given using a
certain CommunicationsResource.
|
| Modifier and Type | Method and Description |
|---|---|
void |
abort()
Aborts the server.
|
private java.lang.Thread |
buildThread(int id,
Actor<?> actor)
Creates a new Thread object to run an Actor.
|
private boolean |
freshRunEvent(FullMessage<P> inMessage)
This method is an event handler to identify and process new runs of the
given protocol that arrive through the communication resource given.
|
java.lang.String |
getInitialAddress(java.lang.String identifier)
Gets the address for the given character in the
initialAddressMap . |
void |
setInitialAddress(java.lang.String identifier,
java.lang.String address)
Sets the address of a character in the
initialAddressMap . |
void |
start()
Starts the Server.
|
void |
stop()
Stops the server.
|
private Server.RunStatus status
Server.RunStatus
private final Part part
private final java.util.concurrent.BlockingQueue<java.lang.Integer> actorIdQueue
private final java.lang.Thread[] threadPool
private final java.util.Map<java.lang.String,java.lang.String> initialAddressMap
private final CommunicationResource<P> communicationResource
public Server(Part part, CommunicationResource<P> communicationResource, java.util.function.Supplier<A> actorFactory, int size)
A
- the Actor type to be used by this Server.part
- the Part to be interpreted by the Server.communicationResource
- the resource to be used to send and receive messages.actorFactory
- a factory to instantiate new Actors (and do any necessary
setup before running).size
- the maximum number of actors that can run simultaneously.private java.lang.Thread buildThread(int id, Actor<?> actor)
id
- the id of the Actor.actor
- the Actor object to be run by the thread.Thread.start()
to start
the thread).private boolean freshRunEvent(FullMessage<P> inMessage)
inMessage
- an incoming message.ReceiveEvent
public void start()
public void stop()
public void abort()
public void setInitialAddress(java.lang.String identifier, java.lang.String address)
initialAddressMap
. This
address is the one (and the only one) that will be used by all protocol
runs. The idea here is to either restrict the addresses that can perform
a certain character or to set addresses that have to be known beforehand
(e.g. a server address).identifier
- the character whose address is being setaddress
- the address to be set for the characterpublic java.lang.String getInitialAddress(java.lang.String identifier)
initialAddressMap
.identifier
- the character for which the address is to be given.


<EMAIL_ADDRESS>Summary
-
A software engineer with more than 8 years of experience in software design
-
Developed applications and infrastructure systems for fintech, transport and educational spheres
-
Result-oriented, focused on business values, strong communication skills, constant learner
-
Interested in UI, practices and paradigms in software, system programming, micro-electronics
Experience
Bolt
I work in a team of 8 engineers. Develop instruments for operating a rental fleet of micro-mobility vehicles such as e-scooters and e-bikes. I'm leading the development of a web back office for managing fleets and a mobile application for operating vehicles.
-
Boosted fleet utilization by 25% by developing features for the mobile application
-
Improved performance of the mobile application by 30% by refactoring and optimizing code
-
Technologies: React Native, Detox, TypeScript, Android Studio
-
Actively participated in the development of the mobile application for operating vehicles
-
Developed a map-based monitoring system for a fleet of micro-mobility vehicles, which becomes a foundation for the same products in the future
-
Technologies: React, TypeScript, WebGL, Google Maps SDK, Node.js, MySQL
Yandex.Money
Participated in the complete cycle of development of a new cash management service with a new for me React Native technology stack: from scratch to launch
-
Developed 20+ screens in the mobile app, enhancing user experience
-
Implemented a React Native native module for tokenization bank cards in the application
-
Created a personal cabinet web application, which allowed business clients to manage accounts and cards
-
Technologies: React Native, TypeScript, Redux, Detox, Fastlane, Swift, Kotlin
Yandex
-
Involved in educational services development for schools and universities with 1000+ students. For example, Yandex.Contest — a platform for programming competitions and a checker system
-
Involved in courses about web development at IFMO as a lecturer and methodologist. Helped in improving the qualification for 30 students with the help of my efforts
-
Technologies: React, TypeScript, Node.js, MongoDB, PostgreSQL
Yandex.Money
-
I was developing back-end and web pages of a high-load check-out system "Yandex.Kassa"
-
Promoted to SSE, and later, in this position, joined the platform team. There I participated in the development of high-load common services for all Yandex.Money products
-
Technologies: Node.js, Jenkins, React, BEM methodology
Cloud Technologies
-
Started as a Junior Software Engineer and was involved in the front-end of the CRM product
-
Later led the development of back-end microservices for that CRM product
-
Technologies: React, Ember.js, Node.js, MongoDB, RabbitMQ, Docker, Kubernetes
Mozilla
Contributed to the development of the Firefox browser and got familiar with the development process of a large open-source project.
Education
-
I practiced dozens of algorithms and data structures with C++, C# and other languages
-
Participated in the ACM ICPC in 2013 and 2014 and reached the semi-finals in 2014
-
My specialization helped me to understand the basics of software development and computer science and to get a good foundation for my future career


Recovered
Infections
Deaths
Countries statistics
Recovery Rate
Death Rate
Confirmed Rate
Epedime Started


Justin Pinder Car Rental
Web Design + Development
Visit Website
The brand was looking to create and launch a website, thus enhancing their online presence. Because Justin Pinder Car Rental didn’t have a website before, we were about to construct their foundation for a new digital era.
The Problem
My challenge was to understand the target market of users who have used car rental services in the past, analyse the competitive landscape of the sites in this category, and to design and develop a seamless, user friendly site.
The Process
In 2017 we worked along side the owners of Justin Pinder Car Rental to design and develop a website for their brand. Given the competitive environment, we had to come up with a strategy that would make the product stand out on the market. From the beginning onwards, we analysed the competitors in the area, to get insights and feedback. Working closely with our target groups helped us define what features we needed to create a unique and performance driven website, that not only showcased the business itself but also provided information that persons visiting the island, might be interested in. By narrowing the focus on the essentials we were able to craft a clean, well designed website for the brand.


Document Information
Preface
Part I Introduction
1. Overview
2. Using the Tutorial Examples
Part II The Web Tier
3. Getting Started with Web Applications
4. JavaServer Faces Technology
5. Introduction to Facelets
6. Expression Language
7. Using JavaServer Faces Technology in Web Pages
8. Using Converters, Listeners, and Validators
9. Developing with JavaServer Faces Technology
10. JavaServer Faces Technology: Advanced Concepts
11. Using Ajax with JavaServer Faces Technology
12. Composite Components: Advanced Topics and Example
13. Creating Custom UI Components and Other Custom Objects
14. Configuring JavaServer Faces Applications
15. Java Servlet Technology
16. Java Servlet Technology: Advanced Topics
17. Internationalizing and Localizing Web Applications
Part III Web Services
18. Introduction to Web Services
19. Building Web Services with JAX-WS
20. Building RESTful Web Services with JAX-RS
21. JAX-RS: Advanced Topics and Example
Part IV Enterprise Beans
22. Enterprise Beans
23. Getting Started with Enterprise Beans
24. Running the Enterprise Bean Examples
25. A Message-Driven Bean Example
26. Using the Embedded Enterprise Bean Container
27. Using Asynchronous Method Invocation in Session Beans
Part V Contexts and Dependency Injection for the Java EE Platform
28. Introduction to Contexts and Dependency Injection for the Java EE Platform
29. Running the Basic Contexts and Dependency Injection Examples
30. Contexts and Dependency Injection for the Java EE Platform: Advanced Topics
31. Running the Advanced Contexts and Dependency Injection Examples
Part VI Persistence
32. Introduction to the Java Persistence API
33. Running the Persistence Examples
34. The Java Persistence Query Language
35. Using the Criteria API to Create Queries
36. Creating and Using String-Based Criteria Queries
37. Controlling Concurrent Access to Entity Data with Locking
38. Improving the Performance of Java Persistence API Applications By Setting a Second-Level Cache
Part VII Security
39. Introduction to Security in the Java EE Platform
40. Getting Started Securing Web Applications
41. Getting Started Securing Enterprise Applications
42. Java EE Security: Advanced Topics and Example
Part VIII Java EE Supporting Technologies
43. Introduction to Java EE Supporting Technologies
44. Transactions
45. Resources and Resource Adapters
46. Running the Resource Adapter Example
47. Java Message Service Concepts
48. Java Message Service Examples
49. Bean Validation: Advanced Topics
50. Using Java EE Interceptors
Part IX Case Studies
51. Duke's Bookstore Case Study Example
52. Duke's Tutoring Case Study Example
53. Duke's Forest Case Study Example
Index
|
|
K
L
- lifecycle of a JavaServer Faces application
- The Lifecycle of the hello Application
- The Lifecycle of a JavaServer Faces Application
- action and value-change event processing, Event and Listener Model
- Apply Request Values phase
- Apply Request Values Phase
- Performing Decoding
- custom converters
- Creating a Custom Converter
- Creating a Custom Converter
- getRendererType method (Render Response phase), Identifying the Renderer Type
- immediate attribute, Understanding the Facelets Page
- Invoke Application phase, Invoke Application Phase
- performing encoding (Render Response phase), Performing Encoding
- Process Validations phase, Process Validations Phase
- renderResponse method
- Overview of the JavaServer Faces Lifecycle
- Apply Request Values Phase
- Process Validations Phase
- Update Model Values Phase
- Render Response phase, Render Response Phase
- responseComplete method
- Overview of the JavaServer Faces Lifecycle
- Process Validations Phase
- Update Model Values Phase
- Restore View phase, Restore View Phase
- saving state, Saving and Restoring State
- tag handlers (Render Response phase), Creating the Component Tag Handler
- updateModels method, Update Model Values Phase
- Update Model Values phase, Update Model Values Phase
- Validator interface, Implementing the Validator Interface
- views, Restore View Phase
- listener classes, Handling Servlet Lifecycle Events
- defining, Defining the Listener Class
- listener interfaces, Defining the Listener Class
- listeners
- HTTP, Securing the GlassFish Server
- IIOP, Securing the GlassFish Server
- local interfaces, Local Clients
- localization, Internationalizing and Localizing Web Applications
- Bean Validation, Localizing Validation Messages
- local transactions, Using JMS API Local Transactions
- log, server, Using the Server Log
- login configuration
- Specifying Authentication Mechanisms
- Specifying an Authentication Mechanism in the Deployment Descriptor
- login method, Authenticating Users Programmatically
- login modules, Using Login Modules
- logout method, Authenticating Users Programmatically
M
- managed bean creation facility, Configuring Managed Beans
- managed bean declarations, Configuring Model Data
- key-class element, Initializing Map Properties
- list-entries element, Initializing Properties Using the managed-property Element
- managed-bean element
- Using the managed-bean Element
- Initializing Managed Bean Properties
- managed-bean-name element, Using the managed-bean Element
- managed-property element, Initializing Properties Using the managed-property Element
- map-entries element
- Initializing Properties Using the managed-property Element
- Initializing Map Properties
- map-entry element, Initializing Map Properties
- null-value elements, Initializing Properties Using the managed-property Element
- value element, Initializing Properties Using the managed-property Element
- managed bean methods
- attributes
- See attributes referencing managed bean methods
referencing
- See referencing managed bean methods
writing
- See writing managed bean methods
- managed bean properties
- Converting a Component’s Value
- Creating a Managed Bean
- Using the EL to Reference Managed Beans
- Binding Component Values and Instances to Managed Bean Properties
- bound to component instances, Writing Properties Bound to Component Instances
- UIData properties, UIData Properties
- UIInput and UIOutput properties, UIInput and UIOutput Properties
- UISelectBoolean properties, UISelectBoolean Properties
- UISelectItem properties, UISelectItem Properties
- UISelectItems properties, UISelectItems Properties
- UISelectMany properties, UISelectMany Properties
- UISelectOne properties, UISelectOne Properties
- writing, Writing Bean Properties
- managed beans, What Is a JavaServer Faces Application?
- composite components, Invoking a Managed Bean
- configuring in JavaServer Faces technology, Using Annotations to Configure Managed Beans
- conversion model, Conversion Model
- custom component alternative, When to Use a Custom Component
- defined for CDI, About CDI Managed Beans
- developing
- Developing the Managed Bean
- Developing a Managed Bean
- event and listener model, Event and Listener Model
- JavaServer Faces technology, Managed Beans in JavaServer Faces Technology
- loading JavaScript, Using the @ResourceDependency Annotation in a Bean Class
- method binding, Using Text Components
- properties
- See managed bean properties
- See also value binding
- Managed Beans specification
- Managed Beans
- Introduction to Contexts and Dependency Injection for the Java EE Platform
- MapMessage interface, Message Bodies
- matrix parameters, JAX-RS, Extracting Request Parameters
- message acknowledgment, Controlling Message Acknowledgment
- bean-managed transactions, Managing Distributed Transactions
- message-driven beans, Using Message-Driven Beans to Receive Messages Asynchronously
- message bodies, Message Bodies
- MessageBodyReader interface, Using Entity Providers to Map HTTP Response and Request Entity Bodies
- MessageBodyWriter interface, Using Entity Providers to Map HTTP Response and Request Entity Bodies
- MessageConsumer interface, JMS Message Consumers
- message consumers, JMS Message Consumers
- message consumption, Message Consumption
- asynchronous
- Message Consumption
- A Simple Example of Asynchronous Message Consumption
- synchronous
- Message Consumption
- A Simple Example of Synchronous Message Receives
- message-driven beans
- Enterprise JavaBeans Technology
- What Is a Message-Driven Bean?
- accessing, What Makes Message-Driven Beans Different from Session Beans?
- coding
- The Message-Driven Bean Class
- Coding the Message-Driven Bean: MessageBean.java
- Coding the Message-Driven Beans for the clientmdbentity Example
- Coding the Message-Driven Bean: ReplyMsgBean.java
- examples
- A Message-Driven Bean Example
- An Application That Uses the JMS API with a Session Bean
- An Application That Uses the JMS API with an Entity
- An Application Example That Consumes Messages from a Remote Server
- An Application Example That Deploys a Message-Driven Bean on Two Servers
- garbage collection, The Lifecycle of a Message-Driven Bean
- introduction, Using Message-Driven Beans to Receive Messages Asynchronously
- onMessage method
- What Makes Message-Driven Beans Different from Session Beans?
- The onMessage Method
- requirements, The Message-Driven Bean Class
- transactions
- What Makes Message-Driven Beans Different from Session Beans?
- Container-Managed Transactions
- Bean-Managed Transactions
- Bean-Managed Transactions
- message headers, Message Headers
- message IDs, JMSMessageID message header field, Message Headers
- Message interface, Message Bodies
- MessageListener interface, JMS Message Listeners
- message listeners
- What Is a Message-Driven Bean?
- JMS Message Listeners
- examples
- Writing the Clients for the Asynchronous Receive Example
- Coding the Application Client: HumanResourceClient.java
- Coding the Application Client: MultiAppServerClient.java
- MessageProducer interface, JMS Message Producers
- message producers, JMS Message Producers
- message properties, Message Properties
- messages
- integrity, Client Authentication
- MessageFormat pattern
- Displaying a Formatted Message with the h:outputFormat Tag
- Using Core Tags
- outputFormat tag, Displaying a Formatted Message with the h:outputFormat Tag
- parameter substitution tags, Using Core Tags
- param tag
- Displaying a Formatted Message with the h:outputFormat Tag
- Using Core Tags
- queueing messages
- Writing a Method to Perform Validation
- Registering Application Messages
- securing, Message-Layer Security
- using the FacesMessage class to create a message, Using FacesMessage to Create a Message
- message security, Overview of Web Application Security
- message selectors, JMS Message Selectors
- messages, JMS
- body formats, Message Bodies
- browsing, JMS Queue Browsers
- definition, JMS API Architecture
- delivery modes, Specifying Message Persistence
- expiration, Allowing Messages to Expire
- headers, Message Headers
- introduction, JMS Messages
- persistence, Specifying Message Persistence
- priority levels, Setting Message Priority Levels
- properties, Message Properties
- messaging, definition, What Is Messaging?
- messaging domains, Messaging Domains
- common interfaces, Programming with the Common Interfaces
- point-to-point, Point-to-Point Messaging Domain
- publish/subscribe, Publish/Subscribe Messaging Domain
- metadata annotations
- resource adapters, Metadata Annotations
- security, Using Annotations to Specify Security Information
- Metamodel API, Overview of the Criteria and Metamodel APIs
- using
- Metamodel Classes in the roster Application
- Using the Metamodel API to Model Entity Classes
- method binding
- method-binding expressions
- Navigation Model
- Configuring Navigation Rules
- method expressions, Enabling Component Properties to Accept Expressions
- method expressions
- Referencing a Managed Bean Method
- Event and Listener Model
- method permissions, Securing an Enterprise Bean Using Declarative Security
- annotations, Specifying Authorized Users by Declaring Security Roles
- mutual authentication
- Mutual Authentication
- Enabling Mutual Authentication over SSL
Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices
|


CMF URL:
Language code:
Load
Here you see the annotated videos for the above specified CMF end-point:


I’m a senior at Florida State University and I'll be graduating this April with a Bachelor of Science degree in Information Technology.
My passion lies in the area of big data, UI design and application development. I would describe myself as a passionate learner and leader; I’m ambitious, motivated and professional. What I look forward to after I graduate is using my passions, skillset, and experience towards a career in designing and developing unique applications that enhance the customers and clients' overall experience, productivity and that can lead to impactful data-driven decisions.
(May 2014 - Present)
(December 2015 - February 2016)
(June 2015 - August 2015)


Figures
Kim Tae-yeon (born March 9, 1989), known mononymously as Taeyeon, is a South Korean singer. She has been a member of SM Entertainment's girl group Girls' Generation since 2007, along with other SM projects including Girls' Generation-TTS, SM the Ballad, and Girls' Generation-Oh!GG. Before officially debuting as a solo singer, Taeyeon had recorded soundtracks for television dramas that proved successful on South Korean music charts, notably "If" and "Can You Hear Me" (2008).She released her debut extended play I in 2015, which includes the Gaon Digital Chart number-one titular single. Her second extended play Why (2016) peaked atop the Gaon Album Chart and spawned two Gaon Digital Chart top-ten singles, "Starlight" and "Why". Her debut studio album, My Voice (2017), yielded the top-five singles "11:11", "Fine" and "Make Me Love You". Sc: Wikipedia


| Property | Type | Description |
|---|---|---|
GnResponseVideoObjects |
Object |
Class Remarks about range values: If you do not set a starting value, the default behavior is to return the first set of results. Range values are available to aid in paging results. Gracenote Service limits the number of responses returned in any one request, so the range values are available to indicate the total number of results, and where the current results fit in within that total. Important: The number of results actually returned for a query may not equal the number of results requested. To accurately iterate through results, always check the range start, end, and total values and the responses returned by Gracenote Service for the query (or queries). Ensure that you are incrementing by using the actual last range end value plus one (range_end+1), and not by simply using the initial requested value. |
rangeEnd |
Long |
Ordinal of the last result in the returned range. |
rangeStart |
Long |
Ordinal of the first result in the returned range. |
rangeTotal |
Long |
Estimated total number of results possible. |
resultCount |
Long |
Total number of result matches. Important: Gracenote Service enforces that the range start value must be less than or equal to the total number of results. If you specify a range start value that is greater than the total number of results, no results are returned. The number of results actually returned for a query may not equal the number of results requested. To accurately iterate through results, always check the range start, end, and total values, and the responses Gracenote returns for the query (or queries). Ensure that you are incrementing by using the actual last range end value plus one (range_end+1), and not by simply using the initial requested value. When paging results, the next page may include results from the previous page, and the result total may also change. This is expected behavior. |
needsDecision |
Boolean |
Flag indicating if user decision needed - either multiple results or single match is determined to be less than perfect |
contributors |
GnContributor |
Contributor objects. See GnVideoWork > videoCredits > contributor for object properties. |
products |
GnVideoProduct |
Video product objects. See GnVideoWork > products for object properties. |
seasons |
GnVideoSeason |
Video season objects. See GnVideoWork > seasons for object properties. |
series |
GnVideoSeries |
Video series objects. See GnVideoWork > series for object properties. |
works |
GnVideoWork |
Video work objects. See GnVideoWork for object properties. |


Final Fantasy Crystal Chronicles Characters
The main playable characters in Crystal Chronicles are all player-made, so only NPCs are listed here.
- Amidatty
- Leader of the Caravan from Shella, Amidatty is a Yuke researcher. He, along with the caravan, travels the world in search of the mysteries behind the miasma plaguing the world. As they uncover these 'truths', Amidatty devises a theory on how the world is like a loaf of Bannock bread - it was fresh when he put it in his bag, but over time, began to mold and decay. The party can really shock this caravan if they choose to take a bite out of the model. Amidatty is apparently quite a popular Yuke as he has a devoted girlfriend in Shella named Eleanor who will extoll on his discoveries and theories. The other members of the Shella caravan are named: Yufina (female), Bessamzan (male), and Leonamiel (female).
- Expand Images
- Artemecion
- Either a crossover or simply a homage to another inky-coated moogle from Final Fantasy IX, Artemecion is the moogle member of the Striped Brigands band of thieves. He's still self-centered and accident prone, and makes a perfect addition to the incompetent team of bandits. Occasionally, this team manages to steal some fruit from the caravan.
- Expand Images
- Bal Dat
- The leader of the Striped Brigands, Bal Dat is a red-haired Selkie who travels the world, not for Myrrh, but for fame and fortune as a skilled thief. His band of followers is small (only three, including himself), but he's dedicated. His code of morals doesn't seem too greatly different from most Selkies, but he's the only one in the game who actually takes part in thievery of any sort.
- Expand Images
- Black Knight
- A Lilty warrior trying to get back the memories of his lost family. He travels the world, mad with confusion, fighting against 'imaginary' monsters. It's said that he has the strength of 20 Lilty warriors and battles in a frenzy. At one point, he is hired by a priest named Hurdy to investigate a swamp that might have clues involving the missing memories. When the party finally comes across him, he is in the midst of finding his answer with his inner demons, before a young Lilty ends his life to avenge his father.

- Expand Images
- Cecil
- The Clavat Elder of Marr's Pass. He seems to think he's quite the ladies' man, despite his age. His granddaughter, Rashe, thinks he's a little senile.
- Expand Images
- Dah Vis & Mana Kohl
- A Selkie couple from Leuda who form the closest thing to a crystal caravan that the port town can claim.  Occasionally, they argue over inane problems and try to get the party involved. Somehow, though, they always get the job done, and if you visit them after they've completed for the year, they'll ask you to join in on their dancing festivities, which is always fun. Dah Vis plays the instruments while Mana Kohl leads the dancing.
- Expand Images
- De Nam
- A Selkie with a purpose in life, this guy is the best alchemist researcher in the game. He figures out the origin of monsters, miasma, and the link between the memory loss and the crystals. He spends his time in Shella amongst the Yukes and clues the party in on most of the mysteries of the world, including how to solve these problems. Apparently he doesn't share the normal Selkie creed.
- Expand Images
- Fiona
- Quite possibly the prettiest character in the game, Princess Fiona is the daughter of a Lilty and a Clavat from Alfitaria. While many of the people in the game do not approve of her, she is determined to learn about the world before she accepts her duties as a princess. However, she goes about it by running away and travelling the world in disguise, much to the chagrin of her Lilty protector, Knocfelna, and his loyal dog. As a half breed, she's quite interesting, with Lilty characteristics such as flower-petal-like hair and steel-gloved arms along with a mostly-Clavat like face and body. When she returns home, she gives the party 1000 Gil each for helping her reach her conclusions.
- Expand Images
- Gurdy
- A Clavat traveler of shady morals, Gurdy comes off as sincere, but in the end turns out to be some sort of pathological liar, leading the party in unusual directions that often turn out poorly. He occasionally works with the Striped Brigands to further his questionable goals. He does, however, give the party useful information in the form of cryptic poems he claims just came to him. Later in the game, it is revealed that he makes up his lies to cover up for the fact that he's lost most of his memory - even the memory of the brother he apparently lives with from clothes he finds in the closet that do not belong to him.
- Expand Images
- Hurdy
- A Clavat priest who travels the world in search of answers to the mysteries of the miasma and the memory loss plaguing the people of the world. He hires the Black Knight during his search of the swamp where many of the answers lie. Hurdy has mysterious relationship with the traveller Gurdy.
- Expand Images
- Jake
- Jake is the Clavat leader of the caravan from the Fields of Fum, where all the world's food supply comes from. His caravan is a friendly lot who enjoy being part of their town's community and being able to protect everyone. This caravan is also more shrewd than one would first expect, and while they freely share their food, they also freely try to sell less useful items for extravagant costs. The other members of the Fum Caravan are named: Sheula (female), Lulie (female), and Andy (male).
- Expand Images
- Ji Meon & Te Odow
- A pair of travelling Selkie merchants, Ji Meon is a trader and merchant, while Te Odow supports him as a money-budgeting wife. The two of them frequent every town in the game and tends to have the best prices.
- Expand Images
- Knocfelna
- He is Princess Fiona's watcher and protector, but this heavily-armored Lilty spends most of the game being her search party. When she runs away, he and his loyal (and also heavily armored) dog are always right behind her, inquiring to the party as to her location. When she returns home to Alfitaria, Knocfelna resumes his position as her guardian.
- Expand Images
- Meh Gat
- An aging Selkie who, along with Bal Dat and Artemecion, forms the team of the Striped Brigands, who rob and plunder unsuspecting crystal caravans. While Meh Gat doesn't seem to have his heart in all the robbing and plundering, he's loyal to Bal Dat, even if he's often asleep at the wrong time during their bungled missions. He's a brave fellow, and Bal Dat takes it hard when Meh Gat dies to save him.
- Expand Images
- Mio
- A princess who feeds on faded memories. She is a benevolent, powerful figure, and by "nibbling" on memories, she encourages people to make new ones. She believes that Raem has gone too far, so she seeks traveling warriors with truly strong memories to rise up and defeat him.
- Expand Images
- Mog
- Mog is your moogle party member when you play Crystal Chronicles single-player. He's the one who'll carry your chalice when you can't do it yourself, though he gets tired easily. He also likes to cast spells to help you out, depending on what color he's been painted. Apparently, moogles like to have their fur painted (and sheared). He may or may not be a crossover character from FF9 or FF6.
- Expand Images
- Raem [VILLAIN]
- The counterpart to Mio. He feeds on the memories of travelers, consuming them totally. He likes dark, painful memories, so he hides the Meteor Parasite from adventurers to foster the miasma to grow over the land, creating as many bad memories as possible. He can only be defeated by the power of strong memories.
- Expand Images
- Roland & Malayde
- An aging Clavat couple who are the Elders of Tipa. Roland is the one who performs the ceremony to regenerate the crystal's energy with Myrrh. The couple seems to be well-informed of events that go on around the world as they always see the party off at the start of each new year with an anecdote for what to keep an eye on this time. (NOTE: Tipa is the default name given to the party's hometown.)
- Expand Images
- Rolfwood
- The Lilty leader of the caravan from Marr's Pass. They seem a bit less personable than the Lilties from Alfitaria. There are only three of them in the caravan, and they claim to be the best blacksmiths and warriors in the world. Rolfwood lets the party know that town Lilties from Marr's Pass and city Lilties from Alfitaria don't get along very well. The other members of the caravan are named: Leuts Royle (this is the talkative one), and Lyne Dott.
- Expand Images
- Sol Racht
- A brave and noble Lilty warrior who leads the caravan from Alfitaria. While he's a nice enough guy, he seems pretty prejudiced that only Lilties can handle themselves in a battle, and will give the party healing items whenever there aren't any Lilties around. His primary quest is to find and subdue the Black Knight, though his team finds time to collect Myrrh, too.
- Expand Images
- Stiltzkin
- A moogle who travels the world in search of the answers behind the miasma... and his own existance. Stiltzkin wonders, "If moogles can remain unaffected by the miasma like monsters, then does that mean that moogles are monsters?" His search takes him through the whole world and he ends up in Mag Mell, investigating the strange occurrences there. He's also a good teacher for battle, and the party can make use of his wisdom. Stiltzkin is almost certainly a crossover character, with the same name, clothing, design, and characteristics as the Stiltzkin that appears in FF9.
- Expand Images
Final Fantasy, all games and animation bearing the Final Fantasy name, and all characters in said games or animation are copyright their respective creators, including but not limited to Squaresoft, Square Enix, Square EA, Tokyo TV, and ADV Films.


class Zlib::ZStream
Zlib::ZStream
is the abstract class for the stream which handles the compressed data. The operations are defined in the subclasses: Zlib::Deflate
for compression, and Zlib::Inflate
for decompression.
An instance of Zlib::ZStream
has one stream (struct zstream in the source) and two variable-length buffers which associated to the input (next_in) of the stream and the output (next_out) of the stream. In this document, “input buffer” means the buffer for input, and “output buffer” means the buffer for output.
Data input into an instance of Zlib::ZStream
are temporally stored into the end of input buffer, and then data in input buffer are processed from the beginning of the buffer until no more output from the stream is produced (i.e. until avail_out
> 0 after processing). During processing, output buffer is allocated and expanded automatically to hold all output data.
Some particular instance methods consume the data in output buffer and return them as a String.
Here is an ascii art for describing above:
+================ an instance of Zlib::ZStream ================+ || || || +--------+ +-------+ +--------+ || || +--| output |<---------|zstream|<---------| input |<--+ || || | | buffer | next_out+-------+next_in | buffer | | || || | +--------+ +--------+ | || || | | || +===|======================================================|===+ | | v | "output data" "input data"
If an error occurs during processing input buffer, an exception which is a subclass of Zlib::Error
is raised. At that time, both input and output buffer keep their conditions at the time when the error occurs.
Method Catalogue¶ ↑
Many of the methods in this class are fairly low-level and unlikely to be of interest to users. In fact, users are unlikely to use this class directly; rather they will be interested in Zlib::Inflate
and Zlib::Deflate
.
The higher level methods are listed below.
Public Instance Methods
Returns the adler-32 checksum.
static VALUE rb_zstream_adler(VALUE obj) { return rb_uint2inum(get_zstream(obj)->stream.adler); }
Returns bytes of data in the input buffer. Normally, returns 0.
static VALUE rb_zstream_avail_in(VALUE obj) { struct zstream *z; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); return INT2FIX(NIL_P(z->input) ? 0 : (int)(RSTRING_LEN(z->input))); }
Returns number of bytes of free spaces in output buffer. Because the free space is allocated automatically, this method returns 0 normally.
static VALUE rb_zstream_avail_out(VALUE obj) { struct zstream *z; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); return rb_uint2inum(z->stream.avail_out); }
Allocates size
bytes of free space in the output buffer. If there are more than size
bytes already in the buffer, the buffer is truncated. Because free space is allocated automatically, you usually don't need to use this method.
static VALUE rb_zstream_set_avail_out(VALUE obj, VALUE size) { struct zstream *z = get_zstream(obj); zstream_expand_buffer_into(z, FIX2INT(size)); return size; }
Closes the stream. All operations on the closed stream will raise an exception.
static VALUE rb_zstream_end(VALUE obj) { zstream_end(get_zstream(obj)); return Qnil; }
Returns true if the stream is closed.
static VALUE rb_zstream_closed_p(VALUE obj) { struct zstream *z; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); return ZSTREAM_IS_READY(z) ? Qfalse : Qtrue; }
Guesses the type of the data which have been inputed into the stream. The returned value is either BINARY
, ASCII
, or UNKNOWN
.
static VALUE rb_zstream_data_type(VALUE obj) { return INT2FIX(get_zstream(obj)->stream.data_type); }
Closes the stream. All operations on the closed stream will raise an exception.
static VALUE rb_zstream_end(VALUE obj) { zstream_end(get_zstream(obj)); return Qnil; }
Returns true if the stream is closed.
static VALUE rb_zstream_closed_p(VALUE obj) { struct zstream *z; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); return ZSTREAM_IS_READY(z) ? Qfalse : Qtrue; }
Finishes the stream and flushes output buffer. If a block is given each chunk is yielded to the block until the input buffer has been flushed to the output buffer.
static VALUE rb_zstream_finish(VALUE obj) { struct zstream *z = get_zstream(obj); zstream_run(z, (Bytef*)"", 0, Z_FINISH); return zstream_detach_buffer(z); }
Returns true if the stream is finished.
static VALUE rb_zstream_finished_p(VALUE obj) { return ZSTREAM_IS_FINISHED(get_zstream(obj)) ? Qtrue : Qfalse; }
static VALUE rb_zstream_flush_next_in(VALUE obj) { struct zstream *z; VALUE dst; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); dst = zstream_detach_input(z); return dst; }
Flushes output buffer and returns all data in that buffer. If a block is given each chunk is yielded to the block until the current output buffer has been flushed.
static VALUE rb_zstream_flush_next_out(VALUE obj) { struct zstream *z; TypedData_Get_Struct(obj, struct zstream, &zstream_data_type, z); return zstream_detach_buffer(z); }
Resets and initializes the stream. All data in both input and output buffer are discarded.
static VALUE rb_zstream_reset(VALUE obj) { zstream_reset(get_zstream(obj)); return Qnil; }
Returns true if the stream is finished.
static VALUE rb_zstream_finished_p(VALUE obj) { return ZSTREAM_IS_FINISHED(get_zstream(obj)) ? Qtrue : Qfalse; }
Returns the total bytes of the input data to the stream. FIXME
static VALUE rb_zstream_total_in(VALUE obj) { return rb_uint2inum(get_zstream(obj)->stream.total_in); }
Returns the total bytes of the output data from the stream. FIXME
static VALUE rb_zstream_total_out(VALUE obj) { return rb_uint2inum(get_zstream(obj)->stream.total_out); }


Loading databases...
Getting matchlist...
Checking if you are in a game...
Solo/Duo
-
-
In Series:
-
/
-
-
/
-
Flex
-
-
In Series:
-
/
-
-
/
-
LP Tracking
You just
a
match


Hi, I'm Stéphane ESTEVE.
I'm 49 and I live in Lyon (France)...
... and I'm looking for a job in
Web Development
.