Posts by ~s.o.s~

I think you should post the latest updated code. That way, maybe I or someone else will give it a look and if it seems like a known issue, will let you know.

That's not a very good implementation, without any logical overrides provided for the equals()/hashCode() method along with the instruction to not *touch* the class, the only option you have is to "inspect" the Node data. E.g. (untested):

private boolean containsItem(BTreeNode<T> current, BTreeNode<T> target) {
    if(current != null) {
        // assumptions:
        // 1. the data pushed into the tree implements logical ordering i.e. Comparable interface
        // 2. the data pushed is never null
        final int cmp = ((Comparable)current.getItem()).compareTo(target.getItem());
        if(cmp > 0) {
            return containsItem(current.getLeft(), target);
        } else if(cmp < 0) {
            return containsItem(current.getRight(), target);
        } else {
            return true;
        }
    } else {
        return false;
    }
}

The regular expression: ([.,!?:;'\"-]|\\s)+ should do the trick. It is read as "for one or more occurrences of either a whitespace or punctuation". The important part here is to make sure that the '+' is kept outside the alternation, since we can have a mix of white-spaces and punctuations.

The problem with your regular expression was that you didn't take into consideration punctuations and whitespaces, but rather punctuation followed by whitespaces. If you have a 'this or that' situation, use alternation. Writing patterns one after another just increases the matching requirement; your pattern read "match any punctuation *followed* by zero or more whitespace characters" which isn't what you wanted. Hence all it did was match punctuations but blew up when faced with white-spaces.

You sure? Can you post the code for your BTreeNode class?

an Enum can be modified in the same way as the database entry, no

They can be modified, but not in the same was as you can do it for database entries. Updated database entries would be visible to the application code almost immediately (or would require flushing the cache if you are caching) but for enum related changes you'd require either a restart (in case we are talking about deployed/managed applications) or an update to client (in case of standalone applications), both of which are pretty involved tasks.

Also, depending on *what* you are representing as key-value pair, it might result in the "enum" solution totally going out of hand with a large number of entries. Also, the database solution would be a good choice if the "would be" enum you talk about would have to be in the end persisted in a database. If for your particular use case, the "enum" is part of only the application logic and not your persistence logic along with having a fixed set of values, the enum solution is a pretty good one.

As already mentioned in my previous post, there can be no black-white answer to this thing; it'd all depend on what you are dealing with though with the points I've raised, you might be better equipped with making a decision.

EDIT: Also, a common anti-patten with enums is to think of them as configurable type-safe entities. If you need something configurable, you are better off using …

As mentioned in my previous post, make sure that your BTreeNode class implements the Comparable<T> interface. Google for tutorials on how to implement it; here is the official one.

bump..

Bumps, and that too soon after posting your thread is rude. It's weekend in almost all parts of the world with Christmas just round the corner. You sure your homework/question is more important than people's personal life? Have some patience.

Anyways, back on topic, regarding your code, a few things come to mind:

• Are you properly overriding the equals() / hashCode() method of the BTreeNode class?
• Rather than checking for equality, you should compare the current node with the desired node to get the desired algorithm behaviour. From wikipedia:

  We begin by examining the root node. If the tree is null, the value we are searching for does not exist in the tree. Otherwise, if the value equals the root, the search is successful. If the value is less than the root, search the left subtree. Similarly, if it is greater than the root, search the right subtree. This process is repeated until the value is found or the indicated subtree is null. If the searched value is not found before a null subtree is reached, then the item must not be present in the tree.

A sample implementation might be:

private boolean containsItem(BTreeNode<T> current, BTreeNode<T> target) {
    if(current != null) {
        if(current.compareTo(target) > 0) {
            return containsItem(current.getLeft(), target);
        } else if(current.compareTo(target) < 0) {
            return containsItem(current.getRight(), target);
        } else {
            return true;
        }
    } else {
        return false;
    }
}

Just implement the Comparable interface and you should be good to go.

They are different yet there is no v/s IMO, there are a few tricks to persisting enums to databases out there, namely writing out the enum name and reading it back by passing the same name to valueOf() method for that enum.

The most obvious difference is that enums are compile time constants whereas key-value pairs stored in databases are configurable. Are you absolutely sure that these mappings won't change over time? If yes, you can have an enum having fixed set of values and when it comes to persisting just persist the enum name which can be easily used to get back the original enum. If you don't have a fixed set of values, the compile time advantage offered by enums is a moot point here since you can't create compile time safe mappings on the fly.

In the end it all depends on *what* exactly you are trying to achieve. But yes, there are ways of mixing and matching enums and database mappings as long as you know what you are dealing with.

I've never worked on Swing/AWT but there are a couple of universal things you should know about single threaded UI toolkit (and Swing is one of them); all UI updates should be done on the rendering thread (EDT - Event dispatcher thread in case of Swing).

The problem with your code is that even though you have the motivation for running a background task, that task is very heavily involved with mutating the UI (getting the text from text area, finding highlights and highlighting them). And since you end up adding highlights in a background thread, it violates the principle of "UI updates only in the EDT. This is the reason you are getting a freeze or technically speaking a "deadlock". I'll also show you how to find out such deadlocks.

Assuming you are running JDK 6, it already comes bundled with a profiling tool called Visual VM in the bin directory. If not, just download it from the official site (google visual vm, it shouldn't be hard). Now, fire up your application and wait for it to freeze. After it has frozen/stopped responding, start Visual VM. After it has started, in the left panel of Visual VM under the "Local" category, you should see the classname of your application. Right click on it and click "Thread Dump". This should give you the thread dump of the currently executing threads. This feature also has the capability of detecting deadlocks. Just navigate to the bottom of that thread dump …

OK, I just looked at the source code of the Socket classes and it seems that closing any one of those three (InputStream, OutputStream, Socket) terminates the connection so that really shouldn't be a problem in your case. But the error message you posted really implies that your system has run out of file descriptors to allocate. If you run into this problem again, make sure you get the entire stack trace for it (based on my previous suggestion of using e.printStackTrace(System.out) .

Another thing you should do is find out the current open file descriptor limit on your machine and see the number of file descriptors used when your server process is running. For all we know, it might be a genuine issue of 'low defaults'. I'm no pro-system admin so you might also want to consult your system administrator for the same.

Post the minimalistic code here which reproduces your problem instead of attaching a zip file.

So do you think if I change it to this method will it work

OK, since it seems only STDOUT is captured by the wrapper code, a better version of your code would be:

e.printStackTrace(System.out)

Ok I will listen your advice in the last part I will close r then what else must I close. Must I close this receivedSocketConn1?

Yes, make it a rule to *always* close all resources you open. It's a good practice anyways, much better than keeping track of what gets closed automatically.

About the refactoring give me some time to absorb it. I will look through and do it and let you have a look

Take your time, one step at a time. First think of splitting all that logic in methods. Good luck.

Thank you

HTH

My O.S is fedora linux. I do not know how to get the entire stack trace printed?

Just make sure that you don't catch any exceptions and gobble them (i.e. don't do anything). Either log that error using Log4J's FATAL logging level or at least do a e.printStackTrace() . Also, make sure that when you start this application on your *nix box, you don't redirect the error stream to /dev/null which might end up gobbling up all your stack traces which might have been printed.

If there was no exception stack trace, how did you know the error was 'too many open files'? Also, how are you starting the application on your *nix box? As a background process?

So normally anything I system.out.println will print in the wrapper log file. So do you think I should do the same for the stack trace?

Exception stack traces are printed out to the *error* stream instead of the standard output stream, so just make sure that your wrapper program captures both error and standard output streams (STDOUT, STDERR).

Another thing regarding the closing of the input stream I read that if w is close then automatically it take of the r too

I don't think so since nothing along those lines is written in the Javadocs for the Socket class. I'd rather play safe and close *all* open resources which were opened; this involves closing socket, input stream and output stream.

I dont know how to split the …

What operating system are you running on? Do you have the entire stack trace?

This error normally comes up when you end up depleting your quota of the maximum acceptable file handles which can be open at a given time which in turn happens if you don't close file/socket streams which you have opened. By having a look at your code, it seems that you never close the InputStream retrieved from the client socket (the variable ' r ') which might be what is causing these errors.

A few more things:

1. Split your logic into methods instead of pushing the entire thing is just a single method
2. Instead of concatenating queries, use PreparedStatement which are immune to SQL injection. For repeated execution they are faster since once a statement is "prepared" the cost of re-compilation of query is no longer there.
3. Spawning threads on demand is expensive; use thread pools. If you are using Java >= 5, look into ExecutorService .
4. Spawning connections on demand is also expensive; use connection pooling if your profiling suggests that the application takes a lot of time in "preparing" database resources

You can create and edit a SQL file which contains all the initialization statements (CREATE, INSERT etc.) using a text editor like Notepad++ which supports SQL highlighting and execute the same in MySQL console using the information provided on this page. The advantage here is that whenever you need to reproduce your entire database environment on a clean MySQL install, you just execute this script and you are done! :-)

MySQL workbench looks awesome in case you are not interested in writing SQL scripts in a text editor and executing them at the console.

It seems that I must define UTF8 for each column of all tables or even recreate the DB and tables with UTF8

This doesn't actually surprise me since we are actually talking about changing the charset here.

which is very rutine task

I'm not sure about the routine part. You are a programmer, it won't be too difficult to whip up a script which does all this for you. :-)

This probably seems to be more of a MySQL problem rather than a Java one; you might also want to try posting this to the official MySQL forum or Daniweb's MySQL forum.

Some interesting threads which I stumbled upon which make it seem as if this is a problem with older versions of MySQL:

http://www.vbulletin.com/forum/showthread.php?121120-SQL-Error
http://forums.mysql.com/read.php?26,6528,6528
http://bugs.mysql.com/bug.php?id=3611

I found one thread related to this topic. However, this thread discusses only Java web-applications.

That really shouldn't make a difference if it is MySQL which is the problem maker here. There is not a frightful lot you can do on the Java side except ensure that the user input is passed to the database engine as "utf-8" encoded string and set the connection properties to support the same.

Unfortunately, we do not live in a perfect world, and this doesn't work because of type erasure.

Why doesn't it work? Instantiating a type parameter won't work, but instantiating parameterized classes which accept a type argument will. The below snippet won't work, but what you posted will.

// doesn't work
public class MyGenericClass<T> {

    private T item;

    public MyGenericClass() {
        item = new T();
    }

}

It's a good idea to use a Buffered stream/reader even for small files. That way, if you encounter performance problems later on, you can tweak the size of the buffer and improve performance without changing a lot of code (just changing buffer size).

But like all performance related things, code tweaked to specific scenarios performs much better than generic code. For e.g. in some cases, it might make more sense to read the *entire* file in a single sweep thereby reducing the system calls even further. Profiling is your friend.

> 1. Line endings are still hacked as there is no readLine.

Raw input streams shouldn't be used for reading character data anyways so this is a moot point. Byte based streams don't have a notion of "line" hence no "readLine()" method. You make the mistake of assuming streams would always be a character based stream.

> We can already have the buffering facility via the proper read() function

No, that's not buffering capability; that's the capability of being allowed to read in multiple bytes in a single sweep. In this case, you don't provide buffering but ensure that minimal number of calls are made to the FS by selecting an appropriate byte array size. Each "read()" call would still need to access the File system in your case. In case of buffered streams, it might so happen that the "buffer" size is much more than the size requested in which case, multiple read invocations can be made without touching the file system.

Is all this impossible to do ourselves? No definitely not, but the question which needs to be asked here is that, do we really need to do this ourselves? :-)

But then why do the docs say that calling markSupported() on an object of FilterInputStream's subclass (like BufferedInputStream) performs in.markSupported() where "in" is the underlying InputStream ?

Because that's what it is; calling mark/reset/markSupported on FilterInputStream *delegates* the call to the InputStream instance with which the FilterInputStream was created. This instance can be *anything* which extends the InputStream class.

At one place it says that that BufferedInputStream adds the mark functionality to InputStreams. If its simply calling the underlying streams mark() method, how is it adding anything ?

I think you are reading docs the wrong way; if a given class *overrides* a given functionality of its superclass, you read the Javadoc for that overridden part instead of the original one present in the superclass.

It's a bit complicated since interacting with external applications which can differ based on the OS/file types isn't exactly Java's forte.

Hardcoding application name/paths works but has a couple of drawbacks:

• Users would typically want the file to be opened with the application with which they have associated the file type. For e.g. computer savvy users normally use other text editing tools like notepad++, vim etc. for editing files instead of notepad.
• The application selection IF ELSE checks need to go down one more level to accommodate different Operating Systems. E.g. windows, linux etc.

You'd require a library which abstracts the file association lookup, something like JDIC. This library isn't exactly user friendly or feature complete but gives you the basic file association lookup functionality. It might be a bit of overhead to include this big a JAR just for file association but the choice is yours. A sample snippet:

package home.projects.misc.classloader;

import org.jdesktop.jdic.filetypes.Action;
import org.jdesktop.jdic.filetypes.Association;
import org.jdesktop.jdic.filetypes.AssociationService;

public class ProcessTest {

    public static void main(final String[] args) throws Exception {
        AssociationService s = new AssociationService();
        Association o = s.getFileExtensionAssociation(".doc");
        Action appAction = o.getActionByVerb("edit");
        String appName = appAction.getCommand().split("\" ")[0].replaceAll("\"", "");
        final ProcessBuilder pb = new ProcessBuilder(appName, args[0]);
        final Process p = pb.start();
        System.out.println("Starting wait");
        System.out.println("Wait status: " + p.waitFor());
        System.out.println("Wait complete");
        new File(args[0]).delete();
    }

    public static void p(Object s) {
        System.out.println(s);
    }
    
}

Play around with the API to get it working as per your specific need.

It's also a possibility that "ping" is disabled on that machine which leads to dropped packets hence the timeouts. Another thing you can try out is "telnet". Try the command telnet <host> <port> for your MySQL and FTP ports. If it works for MySQL and not for FTP server, we might have something there. In any case, post the entire IOException stacktrace.

But how could I delete the file exactly after closing Notepad (or any other lookup program)?

In that case, you need to ditch the Desktop class and look into the Process/ProcessBuilder classes and the `waitFor()' method. Some sample code:

public class ProcessTest {

    public static void main(final String[] args) throws Exception {
        final ProcessBuilder pb = new ProcessBuilder("notepad", args[0]);
        final Process p = pb.start();
        System.out.println("Starting wait");
        System.out.println("Wait status: " + p.waitFor());
        System.out.println("Wait complete");
        new File(args[0]).delete();
    }

}

> So, it seems that port 21 is closed, is it?

No, that implies that the host "109.110.12.236" is unreachable. This seems to be more of a networking issue and nothing to do with Java as such. How is your other host configured? Is it on the same network? If that IP given to you by your hosting provider?

Yes which seems pretty logical given the context in which mark() and reset() methods are used i.e. the "going back" to a mark would be only supported if the underlying stream supports either random FP seeks(RandomAccessFile) or a buffered nature (BufferedInputStream).

i thought it would work ok too if i use in.next() inside the parseInt()

next() leaves the newline character in the stream which is consumed by the nextLine() call. Use nextLine() call throughout your code and you should be good to go.

Show us the entire IOException stacktrace instead of just the error message. Also, if it works locally, it seems more of a networking issue. Are you able to "ping" to that host? Are you able to "telnet" to that host on the given port(21)?

You can have any number/kinds of methods in your RMI server implementation as long as they follow the RMI specification (namely having an interface which extends Remote interface, methods should throw RemoteException, Objects of classes used for communication need to be serializable etc.)

This is a different error; seems more of a networking issue than a Java one. Are you able to ping that host or telnet to that host for the given port?

ping 192.168.1.3
telnet 192.168.1.3 your-port

There are many reasons why you might get a timeout like bad network configuration, firewalls, overloaded server, bad host or port etc.

...says the person who ranks 4th. Hah. [j/k ;-)]

Instead of having a sysout in your catch blocks, put in e.printStackTrace() and post the entire stack trace which comes up on your console (or ide output window). And please post the entire thing, not just the error message.

Read my previous post again; you also need to specify the path of your policy file, not just the system property. It should be:

java -Djava.security.manager -Djava.security.policy="c:/default.policy" RMIClient

Yeah, why not try it out? Also, just to be sure, enclose the values in quotes and use forward instead of back slashes:

java -Djava.security.policy="c:/my.policy" YourClass

You specify a SecurityManager but don't specify a custom policy file which is what is causing the problem here since the "default" java.policy file which comes with the JRE hasn't got the entry which allows you to "connect" to a socket.

The solution here would be to specify your own policy file by creating a new one and specifying it via the -Djava.security.policy="path/to/policy/file". Read the Java security guide for more details. As a start, you can create a policy file which gives the executing Java process all permissions:

grant { 
    permission java.security.AllPermission;
};

Save this piece of code in a file and name it my.policy. Specify the location to this file when using -D switch in the JVM arguments and you should be good to go.

In case your RMI server would be executing untrusted client code, make sure you create a well-thought out security file for the server to ensure that clients from executing arbitrary unsafe code.

It seems that you still haven't read the links I posted since the links clearly make no mention of "rmic". Also, when I say complete stack trace, you need to post the "entire stack trace" which you see on your console or IDE window instead of just the "exception message".

Anyways, try running your RMI service on a higher end port like 12345 and see if it still gives the same problem.

Like already mentioned in my previous post, paste the *entire* stack trace instead of just bits and pieces. Also, if you have made any code changes, post them and make sure that the lines numbers in the stack trace match with those of the posted code.

The exception probably says that a database operation was attempted on a closed connection. Are you using some sort of connection pool? Also, try removing the listeners which initialize quartz and then check if you can issue a simple query to your database in your servlet.

Why does the client only read a single image whereas the server writes out 5 images? Why doesn't the server run in a headless mode i.e. why doesn't it accept the image number from the client or via a configuration rather than popping up a box?

The error probably means that the client closed the connection to the server hence writing out to the "client stream" gives an exception...

The format acceptable by the Naming.lookup method is mentioned in the javadocs of the Naming class. For more information on binding a service to a given name and looking it up when writing the client, refer: rmi server tutorial, rmi client tutorial

Follow the instructions mentioned and re-post again if facing problems with the *complete* stack trace.

EDIT: Also, the concept of Skeletons & stubs has been deprecated. This getting started guide creates a simple client and server without using the deprecated rmic (rmi compiler) for creating stubs.

Tip: Try breaking your posts into logical paragraphs and adding additional line breaks for better readability. The way it is written as of now, it seems like a big "wall of text". :-)

Cross posted at http://www.javaprogrammingforums.com/jdbc-databases/5896-cannot-locate-sun-jdbc-odbc-jbcodbc-driver.html and already solved.

I actually like the idea of your ranking showing up whilst hovering over the avatar. It will give a quick glimpse of a total reputation of the poster, and not just his rep and solved.

But based on the experience with dealing with these kinds of changes, I'm sure someone would comment on the "cluttered" hover box and some might even ask for links in the same. :-)

My other reason for asking about a direct link is because of the time consumption on opening your own page, then selecting the rankings option and then view the rankings. That is like opening 3 pages before you get to what you are looking for. I am sure a lot of posters is going to get annoyed by this, which will eventually result in them not bothered about rankings anyway.

This brings up the question: how much is "just enough" when it comes to presenting data upfront to the user. This is a pretty much involved topic in its own sense (usability I mean) and might require a couple of big changes (e.g. bring fields A, B, C on the profile page to the footer, bring fields X,Y,Z to header etc.).

Now, if I understood the previous posts well enough, it seems that the ranking system is primarily for the newbies, on which I agree.

Not exactly newbies, basically new members who might want to be part of the contributing ecosystem but kind of fail to find the necessary motivation …

The reason for having that link on your profile page as opposed to the site "header" is that it presents you with a personalized view of the ranking at Daniweb. It is a metric which is similar to *your* upvoted posts, your post distribution in different forums, your reputation power etc.

A new link can be added at the top but I feel that it is currently at the right place. Another place would to be place it similar to how reputation and solved thread count are shown on hovering over the avatar, but some might argue about the cluttered interface. So yeah... :-)

The "Top Members by Rank" link next to the member count in the left hand corner at the top of the page works for me, though it doesn't give you the same "relative" personalized view as the one given by your profile page.

But then again, since I'm on the first page, it works out well for me.

┐(￣3￣)┌

You are closing the Statement object which in turn closes the ResultSet which was obtained from it. Read this.

Close the Statement only if you are done with the ResultSet and the Statement object, close the Connection only if you are done with the ResultSet, Statement and Connection objects.

Exception in thread "main" java.lang.NumberFormatException: For input string: " 1.0 2.0 3.0 4.0 5.0 1.0 2.0 3.0 4.0 5.0 1.0 2.0 3.0 4.0 5.0 1.0 2.0 3.0 4.0 5.0 1.0 2.0 3.0 4.0 5.0 1.0 2.0 3.0 4.0 5.0"

OK, let's try it this way: try answering the questions I post.

What do you understand of the error message which you posted? What do you think is the runtime trying to tell you? Can you think of a way wherein you can do away with these runtime exceptions?

Also a suggestion: put aside the entire code you have written for the time being and start afresh. Write a *minimal* piece of code which reproduces the problem for you. It need not be reading from a file; hard-code a string (or string array) and assume that it was read from the file and write a program to achieve the same.

Create a instance variable of type CountDownLatch in the FirstThread class with the initial value of the number of threads for which you want to wait (3 in your case). Pass this instance to the constructors of the thread class for which you'd want to wait. As the final statement of the run() method of your FirstThread class, invoke the await() method of that latch which would "wait" till the latch count reaches 0. At the end of each threads' processing, decrement the count of the latch. By the time your dependent threads are competed, the value of the latch would become 0 which in turn would "wake" up the FirstThread thread.

The exception says that you are passing an entire line to the parseDouble method instead of passing a String which contains a valid double representation. After reading the line, split it (look into the split method of String class) based on whatever separator char you have in the file (comma or space). For each split chunk, remove any superfluous spaces by invoking trim() on that chunk. After that call Double.parseDouble() and you should be good to go.

What happened to the previous thread which you created for the same issue? I thought you had managed to sort it out?