Help coderanch get a
new server
by contributing to the fundraiser

Dan Hop

Greenhorn
+ Follow
since Aug 02, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dan Hop

Hi Folks, I was wondering if anyone else has been down this road before..

Basically I need to read a portion of a text file (log file), that is being written to constantly, and transfer the delta off into a 'new' gzip file.
i.e. every x minutes capture what has changed, dump it off to gzip file, or stream (i.e. I will be sending the gzip data off via an HTTP post to another box).
note: the assumption is that the delta will NOT fit in memory.

I was thinking I would use RandomAccessFile,and simply update the ByteOffset, after each iteration...my question is..should I bother investigating using something like FileChannel/NIO for this (I suspect the FileChannel solution maybe faster..but the question is ... how significantly faster).

thanks
Dano
13 years ago
Hi all, I have a couple of questions in regards to how/when the access logs actually begin to 'see' a request.

In particular, lets say I have a server configured, as follows:
maxThreads=200
acceptCount=100

This configuration implies at most 300 connections can be established, my question is...

1) Will I see Requests in the access log, that never got enqueued (i.e. say the 301 concurrent connection request)..I would think not...
2) In the local Access log valve you can configure duration of request. (does this duration include the time in the 'queue', or is it only the time spent processing the actual request?
i.e. if the local Access log say the request took 30 seconds...does that mean the connection was held for about 30 seconds.or could it say actually have sat in the 'queue' for say 10 minutes..or what-ever..

thanks
Dan
13 years ago
ok well thats weird, I just re-did the same logic in a test app, and its working just like you saw..will have to retry it when I can get back to my original code.

ok well then one follow up..

lets say the return type is of Type String?

how would I test for that..String does not have a 'TYPE' field?


humbled Java Dev...
thanks Dan

13 years ago
This feels like a dumb question..but..How can determine the Object type being returned from a method?

I have tried: where when I call this method with a class and a function that returns and Integer..
it never falls into the Integer section?

what mechanism am I supposed to use to determine the type of t? (In the debugger the value fields shows up as: Class<T> (java.lang.Integer)



13 years ago
well originally I was actually using a ConcurrentHashMap (actually originally I was using ...HashMap..naturally that led to issues), the concurrentHashMap caused a significant performance drop..I believe the main reason is the code does lots and lots of puts, and those are blocking calls.

As such my new strategy is to use the concurrentHashMap as an index into the array (reads are all non-blocking into the map) (be it just int[], or AtomicIntegerArray, or AtomicInteger[]).
That I still need to figure out.

As of right now my array will never shrink (an object added to it will never be removed, and the index will always reference the same object), and it does have a max size, 500 (yeah..atm) 500 AtomicIntegers don't scare me even if 400 of them don't actually ever get used. So I think I'm still leaning towards AtomicInteger[] at the moment.

AtomicInteger[]:
Will insure that no 2 threads will read the same value and increment assuming I use the increment function, and not read/set.

int[] on the other hand:
would allow 2 threads to read the same value and both increment to same value (not good, not disastrous in my case).
but..from what I remember in the early days..jdk 1.2 i++ is NOT thread safe, I think the bits can actually get corrupted since it would allow threads to see partial updates from other threads. based on the word boundaries..this is where I'm not sure.

I think regardless I will start out with AtomicSomething, and perf test it, it I regain the vast majority of the perf drop, then its good enough, with the added advantage it being fully atomic

Adding final on an array declaration doesn't make the references in the array final (just the reference to array itself)..so that wouldn't help in this case..I wouldn't think.
from a performance standpoint I would think there were numerous solutions for Map<Object,primitive> so to speak..

poking around I see there are some implementations with int keys, but nothing with object,int (which Is what I'm looking for).

I suppose it would not be hard to implement one, but.really is that necessary. obviously it would a
ObjectInt map would require less overhead then <Object,Integer>.

thoughts pointers?
13 years ago
Hi folks, I was wonder if it is 'safe' to create a primitive array of ints say:

int[] ints = new int[500];
..//initialize all ints to 0.

then access and increment the array values without any synchronization.
I do NOT care if multiple threads read the same value, then increment/set, I want multiple threads to be able to access/update the array in parallel. (i.e. no blocking across the entire array is a must)

only that each thread when it increments by 1 it will infact increment by 1 based on the value that thread read.
i.e. its ok for n threads to read the value 5, and all of them increment it to the value 6, ideally I would use 'volatile' to avoid this but that is not possible in 1.6..the task at hand is statistical gathering of live data (it does not need to be 100% accurate).

or will doing i++, or i+=2, result in potentially a non-sensical value, since i++ is not atomic?

thoughts?

As an alternative to insure each value is 'atomic' could I do:

AtomicInteger[] ints = new AtomicInteger[500]();
// this would insure each Integer in the array of 500 would be atomic...obviously I would prefer to use int vs the heavier Integer.

is AtomicInteger[] equavlent to AtomicIntegerArray()? (its unclear if this class makes atomic updates across the enter collection on per value basis)

Cheers, and thanks for any advice..