Good Morning K and Chuck

I would suggest that when you call your Thread wait method you specify a wait 
period so your threads wont wait forever and possibly lock the process from 
responding e.g.
wait(long timeout): waits for notification or until the timeout period has 
elapsed; timeout is measured in milliseconds
check out
http://java.sun.com/docs/books/tutorial/essential/threads/waitAndNotify.html
Anyone else?

Martin-

----- Original Message ----- 
From: "KJ R" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Wednesday, December 28, 2005 8:57 AM
Subject: Re: UDP Server app


> Martin and others,
> Thanks for the help.  When I was running both the
> server and client off my local machine, I was getting
> a socketexception on the client - "Address already in
> use: Cannot bind" which makes sense, since they were
> both trying to bind to the same port.  Once I deployed
> my UDPServer to a different machine, I was able send
> udp datagrams successfully and process them on the
> server running in Tomcat.  Now I just need to figure
> out how to stop the component and close the socket.  I
> have a while loop depending on a boolean which I'm
> changing, but when it's blocking on the
> datagramsocket.receive() it won't drop out of the
> loop.  I probably need to start a thread and just end
> the thread.
> 
> K
> 
> --- Martin Gainty <[EMAIL PROTECTED]> wrote:
> 
>> Agreed..
>> To confirm that you are already connected to the
>> specified ports I would encourage you to take a look
>> at 
>> netstat -a which will display all used ports in
>> which case you can then grep for the port to
>> ascertain its 'in use' status
>> 
>> To extend on that concept..Take for instance SunOne
>> which is a J2EE App Server available from Sun 
>> (documentation which is available at
>> http://docs-pdf.sun.com/819-1398/819-1398.pdf)
>> and note that Sun One AppServer allows the
>> specification of Port Range..so that if one port is
>> used Sun One auto-fails over to the next port
>> for that particular subsystem
>> Also BEA supports Port Range scenario for the same
>> reason
>> You can write your own.. but if the AppServer you
>> are using already supports Port Range why bother?
>> Anyone else ?
>> M
>> 
>> ----- Original Message ----- 
>> From: "KJ R" <[EMAIL PROTECTED]>
>> To: "Tomcat Users List" <users@tomcat.apache.org>
>> Sent: Tuesday, December 27, 2005 5:22 PM
>> Subject: RE: UDP Server app
>> 
>> 
>> > Yes I know JNDI itself is not a Tomcat feature,
>> but
>> > their CONNECTION POOL implementation IS a feature
>> I'm
>> > interested in.  I'm not planning on writing my own
>> > connection pool, I like the way they've done it,
>> as
>> > well as their price!  Tomcat also offers
>> advantages in
>> > ease of debugging, error handling,  and
>> integration
>> > with my development environment - Eclipse.  Also
>> as
>> > I've stated I'm much more familiar with Tomcat
>> then
>> > standalone java apps, so sometimes you go with
>> what
>> > you know.
>> > 
>> > That being said, I was able to create a webpage to
>> > initiate the start() method on my class.  It looks
>> > like it's probably working because when I tried to
>> use
>> > my "udp_client" web app to test it, got a message
>> > saying the port was already in use and could not
>> bind,
>> > so I'm getting close.  Any other suggestions?
>> > 
>> > --- "Caldarale, Charles R"
>> > <[EMAIL PROTECTED]> wrote:
>> > 
>> >> > From: KJ R [mailto:[EMAIL PROTECTED] 
>> >> > Subject: RE: UDP Server app
>> >> > 
>> >> >  The main reason to run under Tomcat for me
>> would
>> >> be
>> >> > when I update the database, I'd like to use a
>> JNDI
>> >> > connection pool for my dataaccess class.
>> >> 
>> >> JNDI is not a feature of Tomcat, it's a
>> capability
>> >> of the Java execution
>> >> environment.  Tomcat merely allows you to
>> configure
>> >> JNDI entries
>> >> non-programmatically.  You can accomplish the
>> same
>> >> thing more simply in
>> >> a standalone app with command line parameters.
>> >> 
>> >> You're still subverting the purpose of Tomcat: 
>> it's
>> >> intended to handle
>> >> web applications using HTTP in a request/response
>> >> mode.  Your app isn't
>> >> anything like that - you have no need of a
>> Servlet
>> >> container or any
>> >> other form of J2EE app server.
>> >> 
>> >>  - Chuck
>> >> 
>> >> 
>> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL
>> AND/OR
>> >> OTHERWISE PROPRIETARY
>> >> MATERIAL and is thus for use only by the intended
>> >> recipient. If you
>> >> received this in error, please contact the sender
>> >> and delete the e-mail
>> >> and its attachments from all computers.
>> >> 
>> >>
>> >
>>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail:
>> >> [EMAIL PROTECTED]
>> >> For additional commands, e-mail:
>> >> [EMAIL PROTECTED]
>> >> 
>> >> 
>> > 
>> > 
>> >
>>
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > 
>> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Reply via email to