Prev: Why can nsmc, local classes or anonymous classes have static members ?
Next: Is there any ActiveRecord implementation for java?
From: markspace on 17 Dec 2009 13:47 LC's No-Spam Newsreading account wrote: > I initially see a connection from my http-alt to some arbitrary > port on her system (which my lsof decodes with funny names like > cogitate, tomato-springs, or other names each time different). As John pointed out, these are registered ports. However, that means little, your system can re-use the port numbers with out problems. I'm surprised lsof is bothering to list ports by name, there's only a very small chance this information will be useful. I think these "funny names" are just a red-herring and not relevant to your problem at all. > > Any obvious suggestion that this behaviour might be due to a > Windows/Linux incompatibility ? Or to a bug in my code (but it did work > with other Linux users) ? What I'm seeing mostly here is a lack of any sort of log file or other actual debugging mechanism. Dumping port connections is fine to establish that the software can talk, but it doesn't actually tell us anything, or at least doesn't tell me anything. You should make some kind of log of the session that you can review. This is the only way that I know of short of attaching a debugger. It could be a compatibility problem. Java mostly gets around that, but clever programmers can still find lots of ways to introduce bugs. Since you've established that the systems can connect (open ports), I think the next step is to add some debugging information to the servlet to dump session information, so you can have some hope of debugging the problem (adding logs to the applet will be harder). Assume it's software and debug from that point of view. Bonus points if the logs can be changed per user, so you don't have to write reams of logs for other users that are working correctly.
From: LC's No-Spam Newsreading account on 18 Dec 2009 08:36 On Thu, 17 Dec 2009, markspace wrote: > LC's No-Spam Newsreading account wrote: >> I initially see a connection from my http-alt to some arbitrary >> port on her system (which my lsof decodes with funny names like >> cogitate, tomato-springs, or other names each time different). > > As John pointed out, these are registered ports. However, that means > little, your system can re-use the port numbers with out problems. Not sure about the technical meaning of "registered ports". I assumed lsof is translating port numbers into whatever finds in /etc/services. What puzzled me is that if I run the "foreign application" (i.e. the applet) locally, I see its ports are some arbitrary high numbered port (which seems fine to me). When the applet runs remotely, I see the odd names (which according to /etc/services are relatively low numbered ports) ... so I suppose it is the remote system which is offering such port number for the client sockets. > I think these "funny names" are just a red-herring and not relevant to > your problem at all. Essentially you are saying that using such low numbered registered ports is harmless. Correct ? Is http-alt something which java (or JSDK/jsdk2.1 servlets) does routinely use when listening on a server socket ? > What I'm seeing mostly here is a lack of any sort of log file or other > actual debugging mechanism. Dumping port connections is fine to > establish that the software can talk [...] Since you've established > that the systems can connect (open ports) well, on one hand I've established more than that. Not only ports are open, but the servlet can respond correctly to the simple handshake protocol I designed when the remote client is a manual telnet session on the designated port. On the other hand, I do have logging facilities : - I start the servlet in a dedicated account ssh'd in a dedicated window. The servlet writes to System.out all what it is doing. So I can see there what it does. - The servlet duplicates the same information to the out stream of the http request. So the remote user can see (in the left hand frame of the frameset) what the servlet is doing. - the applet is a rather complex arrangement (a tabbed pane with an image area, a JTable, several controls AND a scrollable message area. I have a button which enables verbose messages, so that the applet wirtes to the message area what it is doing. The point is that all this shows things are working perfectly when I run the applet locally. When it is run remotely simply it gets stuck at some point. So I FIRST had the logging, and since that did not give me any clue, I did lsof port monitoring. The other peculiarity I can mention is that the applet runs natively in my (rather old) firefox on Linux, while my remote user had to install some java plugin to run it in her firefox on Windows. -- ---------------------------------------------------------------------- nospam(a)mi.iasf.cnr.it is a newsreading account used by more persons to avoid unwanted spam. Any mail returning to this address will be rejected. Users can disclose their e-mail address in the article if they wish so.
From: Lew on 18 Dec 2009 09:22 LC's No-Spam Newsreading account wrote: > The other peculiarity I can mention is that the applet runs natively in > my (rather old) firefox on Linux, while my remote user had to install > some java [sic] plugin to run it in her firefox on Windows. Java doesn't run natively. Your Firefox already had the plugin, that's all. -- Lew
From: markspace on 18 Dec 2009 10:27
LC's No-Spam Newsreading account wrote: > Essentially you are saying that using such low numbered registered > ports is harmless. Correct ? Port numbers should not matter. It's just a port. If you can talk on it at all, then it's fine. > The point is that all this shows things are working perfectly when I run > the applet locally. When it is run remotely simply it gets stuck at some > point. You need to find more precisely what that point is. I don't think a log window for the user to look at is going to help here. You'll need finer grained info. Either use a SocketHandler in you app to send logs directly to the server, or write logs to a file and ask the client to upload (or email) them to you. After that, the next step is to attach a debugger directly to the remote system and step through the code yourself. |