Wild guess made without looking at the code:

it may be trying to connect twice because it somehow didnt get hooked up
with the successful java connection to port 1900.

so java has sucessfully engaged port 1900 and is patiently waiting there.

JDEbug may have timed out and attempted to reconnect. but it's discovered
that there is 'some guy' on port 1900 so it tries to get java to start up
with 1901.

java sees no reason to honor the request because it's already busy waiting
on 1900.

thus, two lonely ships pass in the night :-)


again, this is just a guess.

On Fri, 27 Apr 2001, Paul Kinnucan wrote:

> 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