At 12:44 PM 4/27/01 -0400, you wrote:
>I could be wrong, but shouldn't it be using the port information from the
>connected socket (the results of the select) instead of the port from the
>listen/server socket?

I'm sorry I don't understand your point. Here is the code for the connection. 

  public int initConnect() throws JDEException {

    jde.signal(procID, MESSAGE, "initSIOConnect: starting standard I/O
handshake.");

    ServerSocket ss = null;
    try {
      ss = new ServerSocket(0);
    } catch (IOException ex) {
      throw new JDEException("Unable to create a server socket");
    }

    final ServerSocket sstmp = ss;
    final int port = ss.getLocalPort();

    standardIOConnectThread = new Thread("Standard I/O Thread for App
#"+procID) {
        public void run() {
          try {
            jde.signal(procID, MESSAGE, "Debugger waiting for Emacs to connect to
app SIO port " +
                   port + ".");
            sstmp.setSoTimeout(150000);
            sioSocket = sstmp.accept();
            sstmp.close();
            initTransport();
          } catch (IOException ex) {
            jde.signal(procID, ERROR, "IOException occurred while connecting to
app SIO port " + port +
                   ". Shutting down...");
            proc.shutdown();
          } catch (SecurityException ex1) {
            jde.signal(procID, ERROR, "Security exception occurred while
connecting to app SIO port " +
                   port);
          }
        }
      };

    jde.signal(procID, MESSAGE, "initSIOConnect: starting SIO connect
thread.");
    standardIOConnectThread.start();
    return port;

  }

>
>You might try having it return sioSocket.getLocalPort(), which should never
>be wrong.  To try to trace it, you could also log the sstmp.getLocalPort()
>and sioSocket.getLocalPort() either all the time or only when they are
>different.
>

As you can see, it does invoke getLocalPort() to get the port number of the
ServerSocket created by Java.

- Paul

>Just a thought.
>
>Martin
>
>ps. I was going to try out the above, but I wasn't easily able to get the
>environment right for building.  When I have a little more time, I'll see if
>I can do it.  Or, if you make the change and send me the jar file, I'll give
>it a spin and see what happens.
>
>----- Original Message -----
>From: "Paul Kinnucan" <[EMAIL PROTECTED]>
>To: "Javier Lopez" <[EMAIL PROTECTED]>; "Jim Goodwin"
><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Friday, April 27, 2001 11:48 AM
>Subject: RE: JDEBug vs Win2K and/or NT4: Status?
>
>
>> At 11:10 AM 4/27/01 -0400, Javier Lopez wrote:
>> >
>> > I tried it on simple class, (JDE->Debug App)
>> > and I get something like
>> > Error: debugger didn't respond to command:
>> > -1 2607 launch 12 -vmexec javaw -classic
>> >
>> > or something like
>> > No response to command 2612. (process = 13; timeout = 30 sec.)
>> >
>> > But the most intersting one is this one.
>> > this JDE->Debug App wait for it to fail and repeat JDE-Debug App
>> >
>> >  *** Debugger Output for Process Test(2) ***
>> >
>> > Launched VM Java Debug Interface (Reference Implementation) version 1.3
>> > Java Debug Wire Protocol (Reference Implementation) version 1.0
>> > JVM Debug Interface version 1.0
>> > JVM version 1.3.0_01 (Classic VM, native threads, nojit)
>> > initSIOConnect: starting standard I/O handshake.
>> > initSIOConnect: starting SIO connect thread.
>> > Debugger waiting for Emacs to connect to app SIO port 1901.
>> > vm started...
>> > All threads suspended...
>> > Launch command line:
>> >   javaw -classic  Test c:/code/Development/src/ config
>ConfigVariables.vars
>> > tmpl
>> >
>> > Emacs connected to standard IO port 1900 for process Test.
>> > VM options: '-classic '
>> > Gave up waiting for Emacs to connect to SIO port: 1901
>> >
>>
>>
>>
>> Wow! Putting a timout on the socket accept process in JDE-2.2.7beta11
>really
>> paid off. I should have done this ages ago. It appears that for some
>reason
>> Emacs and Java are off by 1 on the socket number. This is the first solid
>> information I've gotten on this problem in about a year and would explain
>the
>> hangup. Now the question is why the difference? I can't look at this right
>now
>> but if anyone else wants to pursue it, here is some background. One of the
>> steps performed by JDEbug when launching an application is to create a
>server
>> socket. JDEbug allows Java to choose the port number of the server socket
>> (e.g., 1900). JDEbug then sends this port number back to the JDE. The JDE
>then
>> triees to connect to the socket on the specified port. What appears is
>that
>> somehow, on some systems,  the port number gets bumped by 1 so that JDEbug
>is
>> waiting on port 1901 while the JDE is trying to connect to port 1900.
>>
>> Any thoughts as to why this might be happening?
>>
>> - Paul
>>
>> >
>> > Javier
>> >
>> >
>> >  -----Original Message-----
>> > From: Jim Goodwin [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, April 27, 2001 10:55 AM
>> > To: '[EMAIL PROTECTED]'
>> > Subject: JDEBug vs Win2K and/or NT4: Status?
>> >>
>> >> Hi all,
>> >>
>> >> I see in the mail-traffic that Paul K has changed the JDEBug code to
>avoid
>> >> setting priority on the thread when launching the debuggee process, in
>an
>> >> effort to cure the problems with deadlocking at launch.
>> >>
>> >> What has not appeared is any user report of whether this has helped or
>> >> cause the problems to go away. Has anyone tried this yet with Win2K
>> >> and/or NT 4? And if so, what experience have y'all had?
>> >> jim
>> >
>> >
>>
>>
>

Reply via email to