Paul Clapham

That's interesting. It looks like the threads are running one at a time, approximately. As if they were waiting to take turns using some resource. No idea what that might be, but reading a file from the file system uses a lot of internal objects including the operating system and its files and Java's internal classes which work with them.

Anyway your Thread code seems to be sound. However, people haven't been using Thread objects to write new multithreaded programs for a long time now. The new and improved tool is called ExecutorService and it's a lot more flexible. Thread is fine to learn how multithreading works, though.

Fernando Sanchez wrote:Thank you for the explanation, so one conclussion I should get is that the multithread alternative does not mean better performance in this case. Am I wrong?

When I try the single-thread program it always takes about between 2.5 and 2.9 seconds to end.
On the other hand the multithread alternative is very unpredictable ranging from 0.6 to 57.3 seconds. I don't understand why there can be so very different results.

You shouldn't assume that running a process in multiple threads will automatically run the process faster. It may happen that the threads interfere with each other in some way, or that they cause some problem like running out of resources. Just for example. I notice that your multithreaded version does run faster than the singlethreaded version sometimes, but I have no idea why it sometimes takes much longer. These things can take a long time to investigate.

So far you only output the number of characters processed by each thread. You might find the time each thread takes to run an interesting piece of information.

No, none of that is of any importance. The code you have will terminate after the longest-running thread finishes and no sooner. Think about it -- if Thread 0 is actually the last to finish, then your waiting loop will wait for it to finish and then quickly notice (in essentially zero time) that the others have already finished. This is true regardless of the finishing order of the threads. And the code can't terminate before the longest-running thread does.

After a bit of web searching I found an article which claims to describe the full process described: The Generic Way To Convert Between Java and PostgreSQL Enums. It sure looks like a cast might help, although that of course is just speculation.

Campbell Ritchie wrote:Please show us how you are selecting your value form the database. How are you casting it?

It maybe looks to me like that error occurs when writing to the database. But anyway, trying to debug Java code without actually seeing the code is pointless. We would need to see the code.

Monica Shiralkar wrote:So, I think It should be specified that we pass instance of annomous class which implements the functional interface.

I don't see why that is true. As far as I can see it's possible to write a class (with a name, of course) which implements the functional interface, and then use an instance of that (non-anonymous) class.

Ah, the famous Scunthorpe problem.

And did its response help you?

Rajkamal Pillai wrote:My question is about how to modify the timeout interval dynamically, other than by making changes to web.xml. What worries me is my suggested solution should not cause performance and/or usability side effects.

It seems like you don't need to extend the timeout interval for everybody, only for some people. If that's not the case and everybody should have an equally extended timeout interval, then just configure that interval into the server.

Otherwise, you're going to need a User object to assign a specified timeout interval for each person who has their timeout interval extended. You'd assign this interval when they sign in and there's no need to do it at any other time. Neither do you need a notification when the server times out. So this requires one message from client to server when the user signs in, without any requirement for the user to do anything. So there's no "usability side effect". If this counts as a "performance side-effect" then you need to go to the person saying that and suggest they start being realistic.

Perhaps I've missed some of your requirements. I'm assuming you don't want security side-effects like allowing the user to leave the session signed in for a long period of time while they are absent from the computer.

Oh right, and I see it's greyed out. So you'd have to change whatever causes the greying out. Or better, hide that menu with all of its useless options and add a Close button to go along with the other buttons.

Bill Melendez wrote:I relooked at the whole setup and decided that I could use LONG VARCHAR instead of Clob.

Excellent idea! I've never used Clob myself -- I imagine it could be useful if you're storing a chapter of a novel in a database cell, or something like that, but just plain text has always been fine for my requirements.

As far as I can see (and I did ask Google Translate the meaning of those buttons) your screen doesn't have a Close button. So there's nothing to activate.

Although, as Campbell mentioned, some details about the design of the form etc would be useful. The picture doesn't explain much.

Let me first suggest that wrapping your test code in a Swing wrapper will just add a layer of confusion. Start by writing some ordinary code which reads data from a database and writes it to the console.

And second, the Clob interface has various methods like length() and getSubstring() and getCharacterStream() which enable you to extract data from a Clob. You've got the getClob() method in your ResultSet. So use those methods to get ahold of the String data.

It looks like I totally don't understand your question at all. What's this "User" object you're talking about? (I don't see anybody in the thread mentioning such a thing.) And what's this login process which requires an unconscionable amount of time to run? (I don't see anything about that in the thread either.) So I'm confused. I thought the question was about how to modify the interval before the server times out a session.

Anil Philip wrote:

Stephan van Hulst wrote:Great, you made it work. Now, never write code like that ever again.

Either use a simple for-loop, or use a collector.

Huh? I am quite proud of what I wrote.

But all of this came from a site called "HackerRank". A "hacker" (before it was somebody who broke into computer system) historically was somebody who wrote quick and dirty code so they could move on to the next hack. Neither version of the word is a compliment. And neither version of the word is anywhere close to describing a professional programmer.