J2EE Java server side error debug interview - java

In a recent job interview I was asked a J2EE debugging question. The question was As Follows:
"You are not getting same data as expected from your server how do you debug it?"
What or how should I answered this question that would make the interviewer happy??
Please suggest....

On the top of my head, usually you would
check the request and compare it with API - is the request being done correctly
check the logs for any problems on the server
confirm that the version of server application matches the one expected
check the database data status
if else fails, try to reproduce the problem locally or in a lower environment or step through the server app execution path with a debugger. Increasing the log level or hooking up to debug interface might be relevant as well.

When you have to debug code to server there is a common way on how to debug the code. You see server logs. Now, if you cannot find any errors, you have to see what the API returns at every single step. If you have not logs for every step, put log.debug("Some text that means something"); and rerun. If something is unusual, then you have to check the specific step.

The question is too general and opens a way for you to literally bombard the interviewer with questions and that's probably what he expects you to do.
Usually when sh. hits the fan I want to know: does the user receive any data at all? If not, app log, server log and db log is where I look. Some apps we use got app log located on the disk where the app is running, some are using db based logs and some are using the default log which can be accessed through admin console on the server (Glassfish for example).
On the other hand if the user received incorrect data I start tracking through the app how the data is "made" which usually means going through several db queries and such where I'm trying to determine what's going on. After that I compare the result I expect with the result user received and according to the difference I decide what went wrong.
But hey this question is too general in this environment so you either let the interviewer specify the problem or create your own scenario for him.

Related

Investigating root cause for long response from application

Application - Struts 1.2, Tomcat 6
Action class calls a service which through DAO executes a query and returns results.
The query is not long running and gives results in seconds when run directly over the database (through SQL client say SQL Developer), but, when the user browses through application front end and same query is run in background through the application, the system hangs and the response either times out or takes a lot of time.
Issue is specific to one particular screen implying that app server to db server connectivity is ok.
Is there a way to enable debug logging of Tomcat/ Struts without any code change, to identify one out of the two scenarios below or any other scenarios possible?
The query is taking the time.
The response is not being sent back to the browser.
P.S. - Debugging or code change to add logging is not an immediate option.
Something to look at is a "Java Profiler". The one that I've used and have liked is YourKit.

Suppress Domino console message "error connecting to server ... the remote server..."

I have an XPages app using Java backend that tries to access mail databases via session.getDatabase("foo", "bar"). My script is only to collect all mail files that the logged in user is able to access (caught via try-catch). But there is one issue:
If the server the script will be executed is not able to reach the other server the well known error message will occur in the log. The message doesn't come from the JVM so it is not caught by my try-catch so far.
Is there a way to suppress this message? It is okay for me not to connect to that databases but I don't wanna get this message on the console.
In production environment I cannot assure that the server has a connection document set up so if I cannot reach it, I'm fine with it.
Any ideas appreciated :)
I strongly believe that the feature you are requesting Oliver is not possible.
The fact that you do not "generate/catch" the message in the JVM is due to the fact that the message is fired by the Notes engine itself (the core) and the JVM just hooks on it.
I have tried the NSPingServer C API as well to simulate your request and see if it would have not generated the error in the log but no luck there as well.
This is part of the core engine and any call you might do using standard LN functions will trigger this message.
If you have direct access to the servers (so no passthrugh) you might try to test if the port is reachable (via sockets) but this is way far too complicated in relation to the actual problem we are talking about.
I hope this helps in some way.
Cheers
Maurizio

Can java.util.logging.Logger methods ever fail on Google App Engine?

Google App Engine uses java.util.logging.Logger (JUL) for all logging. Thus to log anything (and then subsequently retrieve it via the LogService), you just log like you normally do with JUL:
private Logger logger = Logger.getLogger(this.class.getName());
// ...
public void doWhatever() {
logger.info("This will be logged.");
}
But if you read over the GAE tutorials/guides for their various service APIs (Memcache, Mail, Datastore, etc.), they all reiterate that you should always code for the possibility that one of their services are down. GAE even provides a CapabilitiesService that you can check before calling any service method to see if that service is currently enabled or not.
So I ask: is there ever a chance that JUL logging operation will ever fail:
logger.info("Can I ever fail and not get logged?");
If not, why? And if so, what can I do to "failover" in the case that JUL has choked? Thanks in advance.
logger.info("Can I ever fail and not get logged?");
Of course it can fail.
Configuration behind this innocently looking line may:
Write a message to console ( console writes can be not initialized yet, or already shutdown )
Append a message to file ( can fail for many file I/O related reasons )
Send an email ( can fail for many socket I/O related reasons )
Write to DB ( can fail for many DB related reasons )
I've ran into this same problem, and yes the logging service can fail without errors. The best you're going to get (until GAE improves the logging service API), is to cron a job to wake up, say, every minute, and perform a logger.info(...).
Then run a LoggingService#fetchLogs(...), filtered to only retrieve the AppLogLine containing the most recent logger call, and check to make sure you can retrieve it. If you can't, then the logger.info(...) failed, and you can have your app react however you like.
I always expose a secure servlet on my GAE apps that pings the Capabilities Service and asks for a status check on each service. If the service is disabled or down for maintenance, I have an external monitor (that checks this URL every 5 mins) send me a text message. You can tie this "log checking" cron job into that kind of a service check.
One option, if you're consistently crashing and trying to figure something out, is to send async HTTP calls (as a log mechanism) to another server.
Also, because this gave me a smile during several weeks of crashing hell: https://groups.google.com/d/msg/google-appengine/js5CeRWLQZ0/KrW2CpJ4JuYJ
In most systems the Uptime is 100% minus the summation of the downtime of
all other systems. The exception to this rule is logging. When Logging
fails to record the downtime, Uptime goes up. As a result Google has been
working hard to build a logging system that goes down just ahead of all
other systems, and comes up shortly after.

Launching test SMTP server from ColdFusion

We are in the process of creating a training mode for our ColdFusion (9) sites.
The system will allow our users, after logging in, to switch from production mode to training mode by clicking on a link.
When they switch, the data-sources will be switched allowing the data to be safely modified.
We are also going to implement a test SMTP server, using the SubEthaSMTP Java project, in order to capture the emails that are sent from the training mode and display them to the user in a web page.
We can launch the SMTP server as a stand alone process or service without much trouble.
The nicer solution would be to launch server as part of the ColdFuson runtime at the point that the user switches to training mode.
We would create a true Java thread that would persist on a Server level scope for the length of any training sessions and then some arbitrary time out period. If the server times out and a new training session is initiated we would initiate a new SMTP server.
My essential question is, therefore, is it a bad idea to run an ongoing thread in the ColdFusion runtime this way?
I can't see a problem with doing this, although you ought to test to see what resources SubEthaSMTP uses and make sure it's not going to cause you issues. It looks to have minimal dependencies (essentially just SLF4J, which ColdFusion 9 & 10 already provide)
From the example page it looks to be pretty easy to set up and drop into a long-running scope. I think you're right to pick the server scope, as you may have problems using application or anything more volatile, as there'll be a situation where application scope would timeout and be reset, but you'd loose all references to the Mail Server instance.
Please update the post with your findings, as I'd be interested in seeing what you find.

Sending message from server to client with Java

I'm working with Apache Tomcat 7 (JSP and Servlets). In my application, I need to send some messages from server to client. Bellow, I'll explain a little bit what I'm working on.
Brief explanation: The application will bring up a login page if the user isn't logged in every time when he wants to connect to internet. After the user logged in successfully and his time is going to end, I will need to send to client a message with remained time (for example in last few minutes). It can also be another requirement to open advertising popup at a specific time.
I now about JMS but I don't know how fit is that for my scenario. I also read in other posts, the WebSocket can be also an option.
I'm running the server on CentOS 6.2.
Question: For this scenario, do you have some thoughts on how to treat it with Java technologies? If you have some other ideas, feel free to expose!
N.B. Related to JavaScript and PHP I found good answers on SO's questions. I'm interested on how to solve this issue with Java technologies especially.
http://jwebsocket.org/
Maybe this fits your needs.
You will not be able to initiate an HTTP connection from the server to the client. One solution will be to use WebSocket/Comet Framework. Unfortunately websockets are not really wide spread (server+browser) for now. I will suggest you to use a framework to fill the "gap": https://github.com/Atmosphere/atmosphere
I don't understand your obsession with us implementing the solution in Java - any valid solution should be portable across different serverside languages. However if the termination is to occur without synchronous user-driven interaction, then you're just creating load on your server by trying to handle it here. If you want somebody to write the code for you then this isn't the right forum.
I now about JMS....CentOS 6.2.
Not much help here.
The thing we really need to know is what you mean by:
After the user logged in successfully and his time is going to end
(I assume you mean the session time is going to end, unless you've written some software which predicts when people will die).
How do you determine when the session will be ended?
Is it a time limit per page?
Is it a fixed time from when they login?
Is it when the session is garbage collected by the Java?
In the case of 1, then the easiest way to achieve this would be to use javascript to set a timeout on the page (when the user navigates to a new screen the timeout will be discarded), e.g.
setTimeout(function() {
alert('5 minutes has expired since you got here - about to be logged out');
}, (300000)); // 5 minutes
In the 2nd case then you'd still use the method above, but reduce the timeout on the javascript by the time already spent on the server (write the javascript using java, or drop a cookie containing the javascript timestamp at login).
In the 3rd case.....you don't really have any way of knowing when the user will be logged out.

Categories