Steve Harney

Greenhorn
+ Follow
since Jun 19, 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
1
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 Steve Harney

The documentation around the ibm-ejb-jar-bnd.xmi files is non existent. I have done a number of these by hand, or i should say by cut and paste. I would start with building the ear without the xmi files and deploy to a local WebSphere instance, using the detailed path to ensure that i was able to fill in all the bits required for the xmi file. Once the application was deployed i would extract the ejb-jar.xml and the xmi file from WebSphere and use those to update the ejb-jar.xml with the required id's and to build the new ibm-ejb-jar-bnd.xmi file. Depending on how anal retentive you are depends on how far you clean them up.. Once i had something i was happy with i would redeploy, again using the detailed path and confirm i didnt break anything.

Not a pretty process but given the tooling and lack of documentation it worked for me.

Steve.
9 years ago

resh singh wrote:Hi,

While working on the older version of code I see that everywhere in the catch block there is an email getting triggered to the admin.

Like:

try{

}catch(Exception e){
logger.debug("Debug message");
mail.send(, , e.getMessage);
}

I feel this unnecessary, however I want to be sure and would like to get your opinions.

Thanks,
Resh



It is a business decission but you have asked for an opinion so ill give my opinion.

I think the idea of directly call to a send mail on each exception is a bad idea, particularly if its being done to send error emails to the admin. I think it would be better to log the error properly and if emails where required set up an SMTPAppender in my log4j to capture and send the messages.

I would probably end up with something looks like this.


13 years ago
You could also use System.arraycopy, this array will roll multiple spots, if you only need to move it one spot you could get rid of they top and bottom copies.

13 years ago
you could check the queue for messages before asking for one. ie

13 years ago

It is a particularly interesting problem, Henry explained the algorithm, you might be better if someone steps through the input/output.


Take the input
2
3
0 1 0
5
0 1 2 0 1


the 2 means there are two cases ie.
case 1:
3
0 1 0

case 2:
5
0 1 2 0 1

now take case 1.

the three means there are 3 soldiers in the line to start with.

1 2 3

now the 0 1 0 tell them how to move

0 means the first person in the queue will not move..

so after the 0 the line still looks like

1 2 3

next take the 1 .. so the second solder in the line moves one spot to the left.

ie

2 1 3

then finally the last 0 means that the third soldier does not move.

2 1 3.

which is the first part of the output, ( ill leave the second part to you ).

but to help clarify the algorithm if the final digit was say a 2 the third soldier would move two spots to the left ie.

3 2 1



Steve





13 years ago
Looking at the stack

Exception in thread "main" java.util.InputMismatchException
at java.util.Scanner.throwFor(Scanner.java:840)
at java.util.Scanner.next(Scanner.java:1461)
at java.util.Scanner.nextInt(Scanner.java:2091)

and the definition.
Thrown by a Scanner to indicate that the token retrieved does not match the pattern for the expected type, or that the token is out of range for the expected type.

It means that your program has tried to read a value that is an integer that is not an integer.

I really havnt used the scanner but looking at the API i would suspect that its reading a empty string off the end of the first line and cannot form it into a number.
you may consider calling the nextLine() on your scanner after the end of each line.

Steve


13 years ago
Hi Brandon,
The Reason everyone asked to see your code was because we thought it should work, Looking at your Soldier class i can see the issue. Rather than give you the solution Ill try and point you in the right direction.. Start by comparing the age variable in the Quality class (line 4) you originally posted with that of your latest post (line 4). , they is a different and its significant. also compare the age variable between the king class and the soldier class (trick question).

Steve
13 years ago

If you are starting with a java.util.Calendar object i would use a date format ie.



If you are convinced you need to use a string just use the replace method on the String object ie.



Steve
13 years ago


Im not exactly sure where you are getting confused, but i can see that you still have the button action overlapping with the run method the run method should not be referencing the output stream, the output stream should only be used by the button action. the run method is only responsible receiving the messages back from the server and does nothing to send the message to the server.

so i will explain the server,
1. you establish the ServerSocket,
2. while true
3. wait for connection (ssoc.accept())
4. process request from socket
5. close connection
6. return to 2.

The button action in the client will have the following function on each press.

7. establish connection.
8. push the message.
9. close the connection.

your server is blocking at 3 and it will keep blocking until a connection is established, notice there is no mention of the run method from the client, this is only used to receive messages from the server, The run method is responsible from receiving the messages from the server and has nothing todo with the sending, you could not invoke the start() method in the client main, and the client would still be able to send.

You dont have to close the socket on both ends but its best practice todo, as you will get errors if you try and read from a closed socket and if you have explicitly closed it. You have a simple contract between your client and server, they both know that after one message they can close the connection.






Prateek,

Your implementation seemed torn between establishing a new connection everytime and establishing a connection once an using it to send all of the messages, there also seemmed to be some confusion between the run method and button actions.

The run methods in the client i would only ever expect to recieve incoming messages, ie establish a ServerSocket and enter the loop and waits ( ssoc.accept()) when a connection is established it reads the message, processes it and then goes back to waiting. basically the soul purpose of the run method in your client is to process the incoming messages.

The button press however could have been done in several way's the way it is now is that when the send button is pressed, a new connection ( socket ) is made to the server and the message is sent and then the connection is closed, the otherway todo it would be to establish a socket that you could send multiple messages down, although that would require your server to be smarter, ie be able to handle multiple, connections basically accept connection fork a process to handle the new connection and go back to waiting for another connection, to see what im talking about check out the snippet of code i found at http://oreilly.com/catalog/javanut3/chapter/ch04.html#ch04_11.html ( I used to love this book)




I actually prefered your first solution but it just needed a little tweek, inspired by your second solution.



basically, read until you cannot read no more, and if there is nothing available sleep for a little bit and then see what is waiting. It should stop thrashing your cpu and looks closer to your original solution.

Using a ServerSocket/Socket connection will still not give you anything different you still have to wrap it in a stream and you end up with the same issues.

Ok i have had another look at the code, and i actually think that your server is pretty close to the mark. the problem is that you are not actually sending the message the second time. to confirm this.

1. start your server.
2. start your client and send a message.
3. shut down the client.
4. restart your client and send your second message.

The reason your server is not responding is because it is a the ssoc.accept() line is blocking waiting for another connection. I guess the question becomes are you expecting the client to just have one connection to the server or are you expecting it to create a new connection with each new message and then close it down. If its a new connection each time then you will need to modify your client code ( the action associated with the send button) to create the socket and the output stream.

Steve


Although i found at least for me that it was better to learn the constructs ie when to use a for loop, when to use a while loop, when to use if statements. if you can be at a point that you can say i need to use a certain construct you can alway look that up, Knowing what you need and knowing how to find it is most of the battle. after you get experience you will eventually memorise most of the constructs.

I was asked to write a python program a while ago, even without any python experience i was able to sort it out, I was going out on to the web repeatedly to figure out how to write loops and to create objects but I knew what i wanted even if i didnt know how todo it.

Then again it does come back to practice, just remember that keywords can be looked up if you cannot remember them but you need to know what you should be looking for.

Steve.
13 years ago


Hi Prateek,
If you check the output you will be receiving the following stack trace when you are running the client code.

java.net.SocketException: socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2542)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at Client.run(Client.java:24)
at java.lang.Thread.run(Thread.java:619)


I think most of your problems are caused by closing things you shouldnt, and once you have fixed that you may have problems closing things you should.

The main problem i see is that you is because you have closed the Socket ( line 37 of the client code), and it has not been replaced. Try removing the ssoc.close ( line36) and moving the accept and and new ObjectOutputStream into the while loop.
Although make sure you close the Input stream.

Also with your server code it appears you are not closing the "another" socket.
Steve.
I think the TreeSet will give you what you are after, Implement a Comparator to define the order you are after and make sure that your classes implement both the .equals() and .hashcode() methods.

It will remove duplicates and once you are done you can convert it out to an array.

The other option if the values are already in a database table, are you able to form a db query to give you what you are after?

Steve.
13 years ago