Craig
Glad you've had some use out of telnetd bundle - it was just a very
quick hack we did a while back to get us out of a "hole", and it's not
something we've used much of-late.
I'm not sure where this is happening - but I'm pretty sure I know what
is happening.
At startup - the telnetd code will almost certainly be following normal
TCP/IP coding and will create a listener socket, and then accept
incoming connections by on new additional sockets. At close down - I'd
bet that there's no call to disconnect / shutdown the listener socket,
meaning when you try and start up again the port is in use.
One thing that's a little confusing is that your port is still showing
LISTENING - this implies to the OSGi java process itself is not actually
exiting. Usually when a process exits without a clean TCP/IP
close/shutdown, the port will get left something like FIN_WAIT /
TIME_WAIT or CLOSE_WAIT state. I'm 90% sure that there's no way the
socket would be left listening if the process had actually exited, so
I'd be tempted to do a "ps" or Task Manager depending on your platform
to see if you have any zombie java or javaw processes lying around.
Now ... if you do find there is a java zombie lying around, it's
probably a further effect of needing an active "close" of the telnetd
listener. What I'd guess is happening is that the process is set to not
exit whilst daemon threads are lying around, and the since the
"listen()" call has suspended the thread, it's blocked and also
preventing an exit.
The answer here is almost certainly to trap the bundle stop() event
and/or framework shutdown() and call into telnetd to ask to disconnect /
close / shutdown.
I'm afraid at this point I'd need to leave you to investigate further -
at least for now (I'm stuck on a GWT problem at present!) - but
hopefully there's a simple telnetd API call to close down you can try
adding in.
Regards
-- Rob
Craig Phillips wrote:
Rob,
Sorry to trouble you, but you might know off the cuff...
I'm trying to do embedded OSGi... At first, I tried equinox, but it
has a somewhat fatalistic bug (I logged a "DR" with bugzilla), along
with some quirks due to static methods in the starter... So, I moved
to felix.. One note -- I have 'felix.embedded.execution' set to true;
BTW, I have had great mileage from telnetd...
With that said, there's a riddle with embedded felix and the telnetd
port, for which I suspect you already have a inkling about... When I
do a shutdown of the OSGi container (in several of various ways), the
telnetd listen port (6623) is still in an active listening state, as
shown below a la 'netstat -a':
$ netstat -a | grep 6623
TCP MyHostName:6623 MyHostName:0 LISTENING
I replaced the actual host name with 'MyHostName'... not that I'm all
that paranoid, but just sort of out of protective habit, more or less...
When I start up a new OSGi container, the telnetd cannot bind to port
6623 because it's already in use...
I figure, you probably can give me the "low down" / insight into the
story and save me some time/effort... Otherwise, I guess I'll be
digging deeper... I have the source for telnetd (thanks), but not for
the dtw.jar file (I guess there's probably some source out there for
this if I poked around, presumably)...
Appreciate any feedback you can provide and sorry to trouble you,
thanks again, Craig Phillips, Praxis
------------------------------------------------------------------------
*From:* Rob Walker
*Sent:* Tue 5/13/2008 10:13 AM
*To:* Craig Phillips
*Cc:* [email protected]
*Subject:* Re: how to specify telnetd port?
No worries Craig - just a general point, it's usually best to email
the Felix users or dev list (I pick up these lists also - so will
generally respond if around and able to).
I seem to recall this bundle being a very very quick hack - and as
such, I don't think there's an actual property exposed in OSGi config
that controls this.
What it does is use the original underlying TelnetD properties files -
and lookign at the code, I believe the port was specified in
resource/Listener.properties:
this.listenerProps =
PropertiesLoader.loadProperties(this.getClass().getResource("resource/Listener.properties"));
Would be fairly trivial to expose an override to this property - or
else just hack this file within the JAR
BTW - my email has changed, new email is as per this message
Regards
-- Rob
Craig Phillips wrote:
Hi Rob,
Sorry to bother you... My name is Craig Phillips, praxis
engineering... I'm using felix and find the telnetd service very
useful... however, I can't seem to find documentation on how to set
the port... I suspect there is a config.properties entry?
Thanks and sorry to trouble you, Craig
--
Ascert - Taking systems to the Edge
[EMAIL PROTECTED]
+44 (0)20 7488 3470
http://www.ascert.com/
--
Ascert - Taking systems to the Edge
[EMAIL PROTECTED]
+44 (0)20 7488 3470
www.ascert.com
