Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #12561 > unrolled thread

Strange Socket problem

Back to article view | Back to comp.lang.java.programmer

Contents

  Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 11:49 -0800
    Re: Strange Socket problem Steven Simpson <ss@domain.invalid> - 2012-03-01 20:59 +0000
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 13:30 -0800
        Re: Strange Socket problem Steven Simpson <ss@domain.invalid> - 2012-03-01 22:54 +0000
          Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 16:32 -0800
            Re: Strange Socket problem Steven Simpson <ss@domain.invalid> - 2012-03-03 09:08 +0000
              Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 17:48 -0800
    Re: Strange Socket problem markspace <-@.> - 2012-03-01 14:08 -0800
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 16:48 -0800
        Re: Strange Socket problem markspace <-@.> - 2012-03-02 08:33 -0800
          Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-02 15:29 -0800
            Re: Strange Socket problem markspace <-@.> - 2012-03-03 09:33 -0800
              Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 17:55 -0800
                Re: Strange Socket problem markspace <-@.> - 2012-03-03 20:06 -0800
                  Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 21:02 -0800
                    Re: Strange Socket problem "John B. Matthews" <nospam@nospam.invalid> - 2012-03-05 00:00 -0500
                      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-05 09:44 -0800
    Re: Strange Socket problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 22:15 +0000
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 16:43 -0800
        Re: Strange Socket problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 02:01 +0000
    Reiteration: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-01 16:51 -0800
      Re: Reiteration: Strange Socket problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 02:02 +0000
    Re: Strange Socket problem x <x@x.x> - 2012-03-02 21:18 +0100
      Re: Strange Socket problem Lew <noone@lewscanon.com> - 2012-03-02 15:06 -0800
        Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-02 15:38 -0800
          Re: Strange Socket problem Lew <noone@lewscanon.com> - 2012-03-02 16:00 -0800
            Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-02 17:18 -0800
              Re: Strange Socket problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 02:13 +0000
                Re: Strange Socket problem Steven Simpson <ss@domain.invalid> - 2012-03-03 08:41 +0000
                  Re: Strange Socket problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 18:26 +0000
          Re: Strange Socket problem x <x@x.x> - 2012-03-03 11:32 +0100
            Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 17:59 -0800
            Re: Strange Socket problem Lew <noone@lewscanon.com> - 2012-03-03 23:21 -0800
        Re: Strange Socket problem x <x@x.x> - 2012-03-03 10:59 +0100
          Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 18:08 -0800
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-02 15:33 -0800
    Re: Strange Socket problem Paka Small <paka-en@tumia.org> - 2012-03-03 03:32 -0800
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 18:00 -0800
    Re: Strange Socket problem x <x@x.x> - 2012-03-03 12:45 +0100
      Re: Strange Socket problem Knute Johnson <nospam@knutejohnson.com> - 2012-03-03 18:02 -0800

Page 1 of 2  [1] 2  Next page →

#12561 — Strange Socket problem

I'm having a problem in some production code that I can't figure out. 
I'll post the complete actual code below.  This code is running in three 
places and has the same problem in two of them at the same time.  The 
other I'm not sure, it may be that the personnel operating it are 
restarting the program and so don't complain.  This piece of code is a 
simple client that connects via a Socket to a server.  The server 
supplies some data and the client reads that data and files it away.  It 
is supposed to restart itself if there is a connection failure or fault 
for whatever reason.  The problem is that at some random point in time 
the Socket disconnects, the code logs the disconnect but never restarts. 
  It does print the "SportsWinClient Disconnected" message but never 
executes the "fireconnectionEvent()" method after creating a new Socket. 
  It doesn't print any Exception message.  I'm not sure how it gets out 
of the try block without printing the "End of Stream" message or an 
exception message.

The crazy part is that all night long when there is no activity from the 
server it times out and restarts with no problems.

I'm hoping that somebody will see a fault in my code that could cause 
the failure.  It is not a compile problem so I left the formatting as it is.

Thanks for looking.

package com.knutejohnson.xyzcasinos.translux;

import java.io.*;
import java.net.*;
import java.util.*;

import com.knutejohnson.classes.*;

import static com.knutejohnson.xyzcasinos.translux.Constants.*;

public class SportsWinClient implements Runnable {
     private final Thread thread;

     private volatile boolean isConnected;
     private volatile boolean runFlag = true;

     private volatile Socket socket;

     public SportsWinClient() {
         thread = new Thread(this,"SportsWinClient");
     }

     public void start() {
         thread.start();
     }

     public void run() {
//        boolean serverFlag = true;

         System.out.println("SportsWinClient: Started");
         while (runFlag) {
//            String serverAddress = serverFlag ? SPORTS_WIN_IP_PRIMARY :
//             SPORTS_WIN_IP_SECONDARY;
             try {
//                socket = new Socket(serverAddress,SPORTS_WIN_PORT,
                 socket = new Socket(SPORTS_WIN_IP,SPORTS_WIN_PORT,
                  InetAddress.getByName(REMOTE_IP),0);
                 socket.setKeepAlive(true);
                 isConnected = true;

********* I know that the line below is not being executed **********

                 fireConnectionEvent(ConnectionEvent.CONNECTED);
                 socket.setSoTimeout(3600000);  // one hour timeout
                 System.out.println("SportsWinClient: Connected");
                 InputStream is = socket.getInputStream();
                 InputStreamReader isr = new InputStreamReader(is);
                 BufferedReader br = new BufferedReader(isr);

                 String str;
                 while ((str = br.readLine()) != null) {
                     if (!str.matches("\\d+.*"))  // not a sports record
                         continue;
                     SportsBet sb = new SportsBet(str);
                     SPORTS_BET_MAP.put(sb.betNumber,sb);
                 }

                 System.out.println("SportsWinClient: End of Stream");
             } catch (IOException ioe) {
                 System.out.println("SportsWinClient: " + ioe.toString());
             } finally {
                 isConnected = false;
                 if (socket != null)
                     try {
                         socket.close();
                     } catch (IOException ioe) {
                         ioe.printStackTrace();
                     }
                 fireConnectionEvent(ConnectionEvent.DISCONNECTED);
//                serverFlag = !serverFlag;

*********** I know that the line below is being executed *************

                 System.out.println("SportsWinClient: Disconnected");
             }
             // stop interrupts this thread so this will be bypassed on 
a stop
             try {
                 Thread.sleep(10000);
             } catch (InterruptedException ie) { }
         }
         System.out.println("SportsWinClient: Stopping");
     }

     public void disconnect() {
         if (isConnected())
             if (socket != null)
                 try {
                     socket.close();
                 } catch (IOException ioe) {
                     ioe.printStackTrace();
                 }
     }

     public void stop() {
         runFlag = false;
         thread.interrupt();
         if (socket != null)
             try {
                 socket.close();
             } catch (IOException ioe) {
                 ioe.printStackTrace();
             }
     }

     public boolean isConnected() {
         return isConnected;
     }

     private final java.util.List<ConnectionListener> connectionListeners =
      new ArrayList<ConnectionListener>();

     public synchronized void addConnectionListener(ConnectionListener cl) {
         connectionListeners.add(cl);
     }

     public synchronized void 
removeConnectionListener(ConnectionListener cl) {
         connectionListeners.remove(cl);
     }

     private synchronized void fireConnectionEvent(int id) {
         ConnectionEvent ce = new ConnectionEvent(this,id);

         for (ConnectionListener listener : connectionListeners)
             listener.connState(ce);
     }
}



-- 

Knute Johnson

[toc] | [next] | [standalone]

#12563

On 01/03/12 19:49, Knute Johnson wrote:
> It does print the "SportsWinClient Disconnected" message but never 
> executes the "fireconnectionEvent()" method after creating a new 
> Socket.  It doesn't print any Exception message.  I'm not sure how it 
> gets out of the try block without printing the "End of Stream" message 
> or an exception message.

Can you provide an exact trace of the messages that are visible in the 
code you've shown (around the problematic event, of course), just so 
there's no ambiguity about what you're seeing?

>                 System.out.println("SportsWinClient: End of Stream");
>             } catch (IOException ioe) {
>                 System.out.println("SportsWinClient: " + ioe.toString());

Catch Throwable here too, print it out, and rethrow, so we can be sure 
no other exception is slipping through.

>             } finally {
>                 isConnected = false;
>                 if (socket != null)
>                     try {


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#12565

On 3/1/2012 12:59 PM, Steven Simpson wrote:
> On 01/03/12 19:49, Knute Johnson wrote:
>> It does print the "SportsWinClient Disconnected" message but never
>> executes the "fireconnectionEvent()" method after creating a new
>> Socket. It doesn't print any Exception message. I'm not sure how it
>> gets out of the try block without printing the "End of Stream" message
>> or an exception message.
>
> Can you provide an exact trace of the messages that are visible in the
> code you've shown (around the problematic event, of course), just so
> there's no ambiguity about what you're seeing?
>
>> System.out.println("SportsWinClient: End of Stream");
>> } catch (IOException ioe) {
>> System.out.println("SportsWinClient: " + ioe.toString());
>
> Catch Throwable here too, print it out, and rethrow, so we can be sure
> no other exception is slipping through.
>
>> } finally {
>> isConnected = false;
>> if (socket != null)
>> try {
>
>

When the problem arrives, it prints the SportsWinClient: Disconnected 
message and nothing else.  It doesn't reconnect to the server.

I'll try putting in a catch for Throwable but it could take some time 
before I see the problem again.

Thanks,

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12569

On 01/03/12 21:30, Knute Johnson wrote:
> When the problem arrives, it prints the SportsWinClient: Disconnected 
> message and nothing else.  It doesn't reconnect to the server.

What about previous messages (Started, Connected, End of Stream), 
especially for the cycle before the problem?  Do you get this?:

   Started
   Connected
   End of Stream
   Disconnected
   ...
   Connected
   End of Stream
   Disconnected
   Connected
   Disconnected

Or this?:

   Started
   Connected
   End of Stream
   Disconnected
   ...
   Connected
   End of Stream
   Disconnected
   Disconnected

Or is there no previous (successful) cycle?

I'm thinking that maybe a listener is throwing an unchecked exception.

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#12570

On 3/1/2012 2:54 PM, Steven Simpson wrote:
> On 01/03/12 21:30, Knute Johnson wrote:
>> When the problem arrives, it prints the SportsWinClient: Disconnected
>> message and nothing else. It doesn't reconnect to the server.
>
> What about previous messages (Started, Connected, End of Stream),
> especially for the cycle before the problem? Do you get this?:
>
> Started
> Connected
> End of Stream
> Disconnected
> ...
> Connected
> End of Stream
> Disconnected
> Connected
> Disconnected
>
> Or this?:
>
> Started
> Connected
> End of Stream
> Disconnected
> ...
> Connected
> End of Stream
> Disconnected
> Disconnected
>
> Or is there no previous (successful) cycle?
>
> I'm thinking that maybe a listener is throwing an unchecked exception.
>

It cycles fine until it hangs.  All three sites stop within a few 
seconds of each other so it is something that happens on the server end 
I think.  But I have no idea what it could be.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12622

On 02/03/12 00:32, Knute Johnson wrote:
> On 3/1/2012 2:54 PM, Steven Simpson wrote:
>> I'm thinking that maybe a listener is throwing an unchecked exception.
>>
>
> It cycles fine until it hangs.


I'm trying to understand what 'fine' is, and how much of the failing 
cycle appears fine before it fails.  The previous 'fine' cycle must end 
with a "Disconnected" message.  The failing cycle might get as far as 
printing "Connected", before jumping to the "Disconnected" message.

It's just that when you say "it just prints 'Disconnected'", you're 
obviously truncating the entire trace to something manageable, but I 
can't distinguish these cases:

  * You're just showing the last message.
  * You're showing all messages in the final cycle, and they happen to
    include only one message.

These would be distinguishable by truncating just before the last 
message of the previous cycle.  The first case would then be indicated by:

   Disconnected
   Disconnected

...and the second case by:

   Disconnected
   Connected
   Disconnected

I suppose you mean that it's the first case by this:

********* I know that the line below is not being executed **********

                 fireConnectionEvent(ConnectionEvent.CONNECTED);
                 socket.setSoTimeout(3600000);  // one hour timeout
                 System.out.println("SportsWinClient: Connected");

...but I'm not clear on how you know this.

Perhaps you have a listener for the ConnectionEvent, and you can see 
that it doesn't execute.  But that could also mean that it or an earlier 
listener in the chain has thrown an unchecked exception.  
fireConnectionEvent doesn't protect itself against this.


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#12634

On 3/3/2012 1:08 AM, Steven Simpson wrote:
> On 02/03/12 00:32, Knute Johnson wrote:
>> On 3/1/2012 2:54 PM, Steven Simpson wrote:
>>> I'm thinking that maybe a listener is throwing an unchecked exception.
>>>
>>
>> It cycles fine until it hangs.
>
>
> I'm trying to understand what 'fine' is, and how much of the failing
> cycle appears fine before it fails. The previous 'fine' cycle must end
> with a "Disconnected" message. The failing cycle might get as far as
> printing "Connected", before jumping to the "Disconnected" message.
>
> It's just that when you say "it just prints 'Disconnected'", you're
> obviously truncating the entire trace to something manageable, but I
> can't distinguish these cases:
>
> * You're just showing the last message.
> * You're showing all messages in the final cycle, and they happen to
> include only one message.
>
> These would be distinguishable by truncating just before the last
> message of the previous cycle. The first case would then be indicated by:
>
> Disconnected
> Disconnected
>
> ...and the second case by:
>
> Disconnected
> Connected
> Disconnected
>
> I suppose you mean that it's the first case by this:
>
> ********* I know that the line below is not being executed **********
>
> fireConnectionEvent(ConnectionEvent.CONNECTED);
> socket.setSoTimeout(3600000); // one hour timeout
> System.out.println("SportsWinClient: Connected");
>
> ...but I'm not clear on how you know this.
>
> Perhaps you have a listener for the ConnectionEvent, and you can see
> that it doesn't execute. But that could also mean that it or an earlier
> listener in the chain has thrown an unchecked exception.
> fireConnectionEvent doesn't protect itself against this.
>
>

Yes I do have a listener and it doesn't hear.  Once it has stopped the 
listening component says it is not connected.  The connect/disconnect 
messages are in the appropriate order and the last message received is a 
Disconnect message.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12566

On 3/1/2012 11:49 AM, Knute Johnson wrote:
> I'm having a problem in some production code that I can't figure out.


This code below strikes me as possibly being in the wrong order.  If you 
interrupt a thread, it should bail.  But if you close the socket, it 
should do the same thing, and close the socket too (I'm pretty sure 
there's a handshake for TCP for "close me".)

If you interrupt the thread, then close the socket, the "close" might 
never happen.  I'd *just* close the socket, if that passes your testing. 
  Try to let the thread actually execute the close, and then unwind 
naturally.

(I didn't look to see if your thread/runnable has other places it waits 
besides the socket.  If it does, those should be eliminated, replaced 
with other sockets which are also closed, etc.)

[toc] | [prev] | [next] | [standalone]

#12572

On 3/1/2012 2:08 PM, markspace wrote:
> On 3/1/2012 11:49 AM, Knute Johnson wrote:
>> I'm having a problem in some production code that I can't figure out.
>
>
> This code below strikes me as possibly being in the wrong order. If you
> interrupt a thread, it should bail. But if you close the socket, it
> should do the same thing, and close the socket too (I'm pretty sure
> there's a handshake for TCP for "close me".)

Interrupting a thread just sets a flag.  It doesn't do anything unless 
it runs across a method call that will throw an InterruptedException 
(ie. Thread.sleep()).

> If you interrupt the thread, then close the socket, the "close" might
> never happen. I'd *just* close the socket, if that passes your testing.
> Try to let the thread actually execute the close, and then unwind
> naturally.
>
> (I didn't look to see if your thread/runnable has other places it waits
> besides the socket. If it does, those should be eliminated, replaced
> with other sockets which are also closed, etc.)

Not sure what you mean here.  The thread waits on the BufferedReader but 
closing the socket closes the stream which should cause an IOException. 
  The server end closing the stream should cause the read to return null 
and the code should print the End of Stream message which it doesn't so 
I don't think that is where it is getting hung up.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12585

On 3/1/2012 4:48 PM, Knute Johnson wrote:

> Interrupting a thread just sets a flag. It doesn't do anything unless it
> runs across a method call that will throw an InterruptedException (ie.
> Thread.sleep()).

I seem to recall that interrupt() would also cause many types of IO 
operations to abort and exit.  I don't know for sure and I didn't double 
check it.

If it happens at the same time for all clients, have you tried running a 
client locally on your own system so you can observe it directly?  Can 
you run a network trace at the same time?  Can you tell what was being 
sent over the wire immediately before the clients hang?  (Put 
data/commands into a circular buffer then dump the buffer manually.)

What OS does the server run on?  What info/statistics have you tried 
looking at after a hang on the server?

[toc] | [prev] | [next] | [standalone]

#12603

On 3/2/2012 8:33 AM, markspace wrote:
> On 3/1/2012 4:48 PM, Knute Johnson wrote:
>
>> Interrupting a thread just sets a flag. It doesn't do anything unless it
>> runs across a method call that will throw an InterruptedException (ie.
>> Thread.sleep()).
>
> I seem to recall that interrupt() would also cause many types of IO
> operations to abort and exit. I don't know for sure and I didn't double
> check it.

Which would be fine but it is not detecting any kind of Exception.

> If it happens at the same time for all clients, have you tried running a
> client locally on your own system so you can observe it directly? Can
> you run a network trace at the same time? Can you tell what was being
> sent over the wire immediately before the clients hang? (Put
> data/commands into a circular buffer then dump the buffer manually.)

I can't run it here because I can't get to the inside of the network 
that these live on.  I have no way to know what was being sent but all 
of the relevant code is here.  Bad data shouldn't cause any problems but 
that does give me an idea of where to place another trap (thanks).

> What OS does the server run on? What info/statistics have you tried
> looking at after a hang on the server?

I have no idea what OS is running on the server and I can't get any data 
from that end.  I do know that the subprocess that I connect to is there 
to keep me away from the actual server machine.



-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12630

On 3/2/2012 3:29 PM, Knute Johnson wrote:
> I can't run it here because I can't get to the inside of the network
> that these live on.

This is a serious problem, imo.  You must be able to test code in order 
to drive a bug to root cause, and then be able to test a fix.  There's 
no other way.  At minimum you need a test environment that can duplicate 
the issue.  And not having access to real equipment that can test in a 
live environment makes it very very difficult to verify any result.

> I have no way to know what was being sent but all of
> the relevant code is here. Bad data shouldn't cause any problems but
> that does give me an idea of where to place another trap (thanks).

Again, pressing a code listing to your forehead and murmuring words that 
your teachers taught you doesn't fix code.  The whole apparatus must be 
examined in order to find errant behavior.  The idea that the customer 
can wall off part of their system is ridiculous.  Especially because 
it's for their benefit that the system be examined and the problem found.

> I have no idea what OS is running on the server and I can't get any data
> from that end. I do know that the subprocess that I connect to is there
> to keep me away from the actual server machine.

I hope you're getting paid by the hour and not for any particular result.

[toc] | [prev] | [next] | [standalone]

#12635

On 3/3/2012 9:33 AM, markspace wrote:
> On 3/2/2012 3:29 PM, Knute Johnson wrote:
>> I can't run it here because I can't get to the inside of the network
>> that these live on.
>
> This is a serious problem, imo. You must be able to test code in order
> to drive a bug to root cause, and then be able to test a fix. There's no
> other way. At minimum you need a test environment that can duplicate the
> issue. And not having access to real equipment that can test in a live
> environment makes it very very difficult to verify any result.

They can't risk having me have access to the server from my location 
because for several reasons not the least of which it would be illegal. 
  All of the clients connect to the servers through Cisco hardware VPNs 
which is another reason they don't want me to be able to get in from the 
outside.  I can however travel to the client's location and hook up, I 
just don't want to for several other reasons.

>> I have no way to know what was being sent but all of
>> the relevant code is here. Bad data shouldn't cause any problems but
>> that does give me an idea of where to place another trap (thanks).
>
> Again, pressing a code listing to your forehead and murmuring words that
> your teachers taught you doesn't fix code. The whole apparatus must be
> examined in order to find errant behavior. The idea that the customer
> can wall off part of their system is ridiculous. Especially because it's
> for their benefit that the system be examined and the problem found.

I don't think the problem can be caused by bad data.  If you see 
someplace where you think that could be, please feel free to point it out.

>> I have no idea what OS is running on the server and I can't get any data
>> from that end. I do know that the subprocess that I connect to is there
>> to keep me away from the actual server machine.
>
> I hope you're getting paid by the hour and not for any particular result.

That would be really nice wouldn't it :-).

One of the sites' personnel are pretty savvy and just restart the 
program when this happens.  The other two call in house tech support, 
who then calls my boss, who then calls me and I restart it.  What I 
would like to do is figure out why it quits so I don't have to hear from 
them.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12647

On 3/3/2012 5:55 PM, Knute Johnson wrote:

> One of the sites' personnel are pretty savvy and just restart the
> program when this happens. The other two call in house tech support, who
> then calls my boss, who then calls me and I restart it. What I would
> like to do is figure out why it quits so I don't have to hear from them.


You're going to have to camp out in their machine room until you find 
it.  There probably isn't any other way.  So far I think we can add 
"Cisco VPN" to the list of things that may be giving up the ghost.

BTW, why do you keep referring to bad data?  I never mentioned bad data 
that I can recollect.  I mentioned hardware, operating systems, 
debugging, diagnostics, and the need to collect diagnostic information 
from the systems involved.  I never mentioned data.

My guess is it isn't in the Java code at all, it's somewhere else. 
Cisco pretty famous for ignoring specs and RFCs and just doing their own 
thing.  It causes lots of weird incompatibilities with just about 
everything.

[toc] | [prev] | [next] | [standalone]

#12652

On 3/3/2012 8:06 PM, markspace wrote:
> On 3/3/2012 5:55 PM, Knute Johnson wrote:
>
>> One of the sites' personnel are pretty savvy and just restart the
>> program when this happens. The other two call in house tech support, who
>> then calls my boss, who then calls me and I restart it. What I would
>> like to do is figure out why it quits so I don't have to hear from them.
>
>
> You're going to have to camp out in their machine room until you find
> it. There probably isn't any other way. So far I think we can add "Cisco
> VPN" to the list of things that may be giving up the ghost.
>
> BTW, why do you keep referring to bad data? I never mentioned bad data
> that I can recollect. I mentioned hardware, operating systems,
> debugging, diagnostics, and the need to collect diagnostic information
> from the systems involved. I never mentioned data.
>
> My guess is it isn't in the Java code at all, it's somewhere else. Cisco
> pretty famous for ignoring specs and RFCs and just doing their own
> thing. It causes lots of weird incompatibilities with just about
> everything.
>
>
>

Because the only thing two things I can think of right now are bad data 
causing an exception that I'm not seeing for some reason or something in 
the TCP/IP connection sequence that is blocking the socket creation and 
hanging the code at that point.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12699

In article <jiut0d$vfh$1@dont-email.me>,
 Knute Johnson <nospam@knutejohnson.com> wrote:

> On 3/3/2012 8:06 PM, markspace wrote:
> > On 3/3/2012 5:55 PM, Knute Johnson wrote:
> >
> >> One of the sites' personnel are pretty savvy and just restart the 
> >> program when this happens. The other two call in house tech 
> >> support, who then calls my boss, who then calls me and I restart 
> >> it. What I would like to do is figure out why it quits so I don't 
> >> have to hear from them.
> >
> > You're going to have to camp out in their machine room until you 
> > find it. There probably isn't any other way. So far I think we can 
> > add "Cisco VPN" to the list of things that may be giving up the 
> > ghost.
> >
> > BTW, why do you keep referring to bad data? I never mentioned bad 
> > data that I can recollect. I mentioned hardware, operating systems, 
> > debugging, diagnostics, and the need to collect diagnostic 
> > information from the systems involved. I never mentioned data.
> >
> > My guess is it isn't in the Java code at all, it's somewhere else. 
> > Cisco pretty famous for ignoring specs and RFCs and just doing 
> > their own thing. It causes lots of weird incompatibilities with 
> > just about everything.
> 
> Because the only thing two things I can think of right now are bad 
> data causing an exception that I'm not seeing for some reason or 
> something in the TCP/IP connection sequence that is blocking the 
> socket creation and hanging the code at that point.

Any chance they started preemptively rebooting errant hardware at a time 
that correlates with your observation?

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#12716

On 3/4/2012 9:00 PM, John B. Matthews wrote:
>> Because the only thing two things I can think of right now are bad
>> data causing an exception that I'm not seeing for some reason or
>> something in the TCP/IP connection sequence that is blocking the
>> socket creation and hanging the code at that point.
>
> Any chance they started preemptively rebooting errant hardware at a time
> that correlates with your observation?

I think that is likely but I have no way to get that information.  The 
company holds tight to information like that.

I've put in code to trap any Throwable and also to look for the 
possibility of bad data.  Now I just have to wait and see if it happens 
again.

Thanks for looking.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12567

On Thu, 01 Mar 2012 11:49:30 -0800, Knute Johnson wrote:

> I'm having a problem in some production code that I can't figure out.
> I'll post the complete actual code below.  This code is running in three
> places and has the same problem in two of them at the same time.  The
> other I'm not sure, it may be that the personnel operating it are
> restarting the program and so don't complain.  This piece of code is a
> simple client that connects via a Socket to a server.  The server
> supplies some data and the client reads that data and files it away.  It
> is supposed to restart itself if there is a connection failure or fault
> for whatever reason.  The problem is that at some random point in time
> the Socket disconnects, the code logs the disconnect but never restarts.
>   It does print the "SportsWinClient Disconnected" message but never
> executes the "fireconnectionEvent()" method after creating a new Socket.
>   It doesn't print any Exception message.  I'm not sure how it gets out
> of the try block without printing the "End of Stream" message or an
> exception message.
> 
> The crazy part is that all night long when there is no activity from the
> server it times out and restarts with no problems.
>
I notice that InetAddress.getByName() can throw UnknownHostException (and 
this exception isn't explicitly handled. Is it possible that this call 
can time out when the network is busy?  

However, as UnknownHostException is a subclass of IOException I don't see 
how it avoids being caught, unless a timeout causes a null to be 
returned: the description of getByName() isn't at all clear about when a 
null is returned instead of throwing an exception. Pulling this out of 
the new Socket() statement so it can be tested for a null return would at 
least show whether this is happening. 

Also, I don't see why you're using InetAddress to pass what is apparently 
a remote address to the Socket constructor as localAddress, or why you're 
using port zero  as the local port.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#12571

On 3/1/2012 2:15 PM, Martin Gregorie wrote:
> On Thu, 01 Mar 2012 11:49:30 -0800, Knute Johnson wrote:
>
>> I'm having a problem in some production code that I can't figure out.
>> I'll post the complete actual code below.  This code is running in three
>> places and has the same problem in two of them at the same time.  The
>> other I'm not sure, it may be that the personnel operating it are
>> restarting the program and so don't complain.  This piece of code is a
>> simple client that connects via a Socket to a server.  The server
>> supplies some data and the client reads that data and files it away.  It
>> is supposed to restart itself if there is a connection failure or fault
>> for whatever reason.  The problem is that at some random point in time
>> the Socket disconnects, the code logs the disconnect but never restarts.
>>    It does print the "SportsWinClient Disconnected" message but never
>> executes the "fireconnectionEvent()" method after creating a new Socket.
>>    It doesn't print any Exception message.  I'm not sure how it gets out
>> of the try block without printing the "End of Stream" message or an
>> exception message.
>>
>> The crazy part is that all night long when there is no activity from the
>> server it times out and restarts with no problems.
>>
> I notice that InetAddress.getByName() can throw UnknownHostException (and
> this exception isn't explicitly handled. Is it possible that this call
> can time out when the network is busy?

That's possible I guess but I would think it would still throw an 
UnknownHostException.  Also, since I pass it a string with the IP 
address specified with digits, it doesn't have to do any DNS lookup.

> However, as UnknownHostException is a subclass of IOException I don't see
> how it avoids being caught, unless a timeout causes a null to be
> returned: the description of getByName() isn't at all clear about when a
> null is returned instead of throwing an exception. Pulling this out of
> the new Socket() statement so it can be tested for a null return would at
> least show whether this is happening.
>
> Also, I don't see why you're using InetAddress to pass what is apparently
> a remote address to the Socket constructor as localAddress, or why you're
> using port zero  as the local port.

The computer has two NICs.  The LOCAL_IP is the address of the NIC that 
I want to use to connect to the server.  Having to use InetAddress is a 
limitation of the Socket constructor.  Port 0 is the ephemeral port.  It 
allows the socket implementation to select any available port for the 
client end.  I'm not sure how InetAddress.getByName() can return a null.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#12614

On Thu, 01 Mar 2012 16:43:25 -0800, Knute Johnson wrote:

> On 3/1/2012 2:15 PM, Martin Gregorie wrote:
>> On Thu, 01 Mar 2012 11:49:30 -0800, Knute Johnson wrote:
>>
>>> I'm having a problem in some production code that I can't figure out.
>>> I'll post the complete actual code below.  This code is running in
>>> three places and has the same problem in two of them at the same time.
>>>  The other I'm not sure, it may be that the personnel operating it are
>>> restarting the program and so don't complain.  This piece of code is a
>>> simple client that connects via a Socket to a server.  The server
>>> supplies some data and the client reads that data and files it away. 
>>> It is supposed to restart itself if there is a connection failure or
>>> fault for whatever reason.  The problem is that at some random point
>>> in time the Socket disconnects, the code logs the disconnect but never
>>> restarts.
>>>    It does print the "SportsWinClient Disconnected" message but never
>>> executes the "fireconnectionEvent()" method after creating a new
>>> Socket.
>>>    It doesn't print any Exception message.  I'm not sure how it gets
>>>    out
>>> of the try block without printing the "End of Stream" message or an
>>> exception message.
>>>
>>> The crazy part is that all night long when there is no activity from
>>> the server it times out and restarts with no problems.
>>>
>> I notice that InetAddress.getByName() can throw UnknownHostException
>> (and this exception isn't explicitly handled. Is it possible that this
>> call can time out when the network is busy?
> 
> That's possible I guess but I would think it would still throw an
> UnknownHostException.  Also, since I pass it a string with the IP
> address specified with digits, it doesn't have to do any DNS lookup.
>
Agreed. 

All I wanted to do was to flag up that its odd that the Javadocs say that 
sometimes it returns null without (apparently) throwing an exception but 
don't say explicitly what governs each behaviour, and that it would be 
useful to call it in such a way that that you force it to make that 
distinction explicit.

>> However, as UnknownHostException is a subclass of IOException I don't
>> see how it avoids being caught, unless a timeout causes a null to be
>> returned: the description of getByName() isn't at all clear about when
>> a null is returned instead of throwing an exception. Pulling this out
>> of the new Socket() statement so it can be tested for a null return
>> would at least show whether this is happening.
>>
>> Also, I don't see why you're using InetAddress to pass what is
>> apparently a remote address to the Socket constructor as localAddress,
>> or why you're using port zero  as the local port.
> 
> The computer has two NICs.  The LOCAL_IP is the address of the NIC that
> I want to use to connect to the server.  Having to use InetAddress is a
> limitation of the Socket constructor.  Port 0 is the ephemeral port.  It
> allows the socket implementation to select any available port for the
> client end.  I'm not sure how InetAddress.getByName() can return a null.
>
OK.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web