please take this to jboss-user, try respecting the boundaries of the lists
and not answering or politely redirecting to jboss-user when appropriate, I
believe the word on jboss-user is "go to jboss-dev for an answer"... not
good,

marcf

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Cao
|Sent: Wednesday, June 13, 2001 4:26 PM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] UnClean Shutdown: Port already in use:
|
|
|Thanks, I do check and found that there is NO java process running after i
|shutdown Jboss, during this time, I didn't touch any other
|program, but some
|problem remains, looks like few sub process in Jboss failed to end
|itself, I
|don't know is there any body else count this problems?
|
|
|David Cao
|- Energizing by Thinking
|
|
|
|-----Original Message-----
|From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, June 13, 2001 11:24 AM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] UnClean Shutdown: Port already in use:
|
|
|Hello,
|
|I am not sure this is the problem. Please check in the taskmanager
|if a java
|process is still present.
|
|If it is not the case, it is possible that a Windows service has
|termporarly
|opened a TCP port for any reason. You may find some usefull tool to detect
|to which process is linked a port at http://www.sysinternals.com/, more
|accuratly : http://www.sysinternals.com/ntw2k/source/tcpview.shtml
|
|Cheers,
|
|
|                                                               Sacha
|
|
|
|
|> -----Message d'origine-----
|> De : [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]De la part de
|> David Cao
|> Envoy� : mercredi, 13 juin 2001 20:12
|> � : '[EMAIL PROTECTED]'
|> Objet : [JBoss-dev] UnClean Shutdown: Port already in use:
|>
|>
|> Hi,
|>
|> I got an unclean shutdown problem ( in windows 2000 server), it happened
|> some times, after I shutdown the server, and start it, i get this
|> error when
|> deploy ejb:
|>
|> [Container factory] java.rmi.ServerException: Could not bind
|> either home or
|> invo
|> ker; nested exception is:
|> [Container factory]     java.rmi.server.ExportException: Port already in
|> use: 44
|> 44; nested exception is:
|> [Container factory]     java.net.BindException: Address in use: JVM_Bind
|> [Container factory] java.rmi.server.ExportException: Port already in use:
|> 4444;
|> nested exception is:
|> [Container factory]     java.net.BindException: Address in use: JVM_Bind
|> [Container factory] java.net.BindException: Address in use: JVM_Bind
|>
|> Thanks a lot.
|>
|> David Cao
|> - Energizing by Thinking
|>
|>
|>
|> -----Original Message-----
|> From: Bill Burke [mailto:[EMAIL PROTECTED]]
|> Sent: Wednesday, June 13, 2001 10:50 AM
|> To: [EMAIL PROTECTED]
|> Subject: RE: [JBoss-dev] Should CacheKey copy its id on creation?
|>
|>
|> My bad,  I didn't look hard enough.
|>
|> Forgive me? :-)
|>
|> Bill
|>
|> > -----Original Message-----
|> > From: [EMAIL PROTECTED]
|> > [mailto:[EMAIL PROTECTED]]On
|Behalf Of Scott
|> > M Stark
|> > Sent: Wednesday, June 13, 2001 1:22 PM
|> > To: [EMAIL PROTECTED]
|> > Subject: Re: [JBoss-dev] Should CacheKey copy its id on creation?
|> >
|> >
|> > >
|> > > If you don't believe it, how come when we turned off Optimized
|> > everything
|> > > worked.  As a different test, we didn't share PrimaryKey
|> instances when
|> > > calling findByPrimaryKey, and that worked as well!  I'm not
|> crazy here.
|> > > I've been looking at this code for more than a week now trying
|> > to figure out
|> > > why our InstanceCache was all fucked up and finally, finally
|found the
|> > > solution.  BTW, the Optimized flag isn't even documented within
|> > JBoss.....
|> > >
|> >
|> > Sure it is, from: http://www.jboss.org/documentation/HTML/ch06s08.html
|> >
|> > <container-invoker-conf> configuration of the container invoker.
|> >
|> > There are several elements which can nest within
|> > container-invoker-conf, one of which is <Optimized>. This
|> > controls the behavior of
|> > bean method calls within the Java VM in which jboss is running.
|> > If the value of Optimized is "false" then the container will behave
|> > per the EJB spec and all objects passed into and out of bean
|> > remote methods will be marshalled over RMI regardless of whether the
|> > client is running remotely or in the same VM as jboss.
|> >
|> > If the value of Optimized is "true" then objects passed between
|> > bean methods and clients in the jboss java VM will be passed by
|> > reference rather than by value. This is much more efficient (and
|> > can result in substantial performance improvements) but can result
|> > in unexpected behavior. For example, if a bean has a member
|> > object and returns that object from a get() method then the
|> > EJB-specified behavior is to make a copy of that object which is
|> > returned over RMI to the caller. Therefore if the caller modifies
|> > the returned object in any way she will modify the copy of the
|> > object. If Optimized is "true" then the caller will modify the
|> > original object per se, rather than a copy.
|> >
|> >
|> >
|> >
|> > _______________________________________________
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to