simpleweb-support Mailing List for Simple (Page 15)
Brought to you by:
niallg
You can subscribe to this list here.
2004 |
Jan
(1) |
Feb
(4) |
Mar
(2) |
Apr
(14) |
May
(22) |
Jun
(15) |
Jul
(9) |
Aug
(2) |
Sep
(7) |
Oct
(4) |
Nov
(2) |
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(7) |
Feb
(16) |
Mar
(17) |
Apr
|
May
(12) |
Jun
(4) |
Jul
(22) |
Aug
(50) |
Sep
(8) |
Oct
(23) |
Nov
(9) |
Dec
(50) |
2006 |
Jan
(6) |
Feb
(7) |
Mar
(8) |
Apr
(3) |
May
(13) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(7) |
2007 |
Jan
(11) |
Feb
(3) |
Mar
(17) |
Apr
(21) |
May
(9) |
Jun
(4) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(14) |
Dec
(3) |
2008 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(15) |
Oct
(9) |
Nov
(6) |
Dec
(2) |
2009 |
Jan
(29) |
Feb
(2) |
Mar
(8) |
Apr
(14) |
May
(4) |
Jun
(13) |
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(7) |
2010 |
Jan
|
Feb
(2) |
Mar
(61) |
Apr
(9) |
May
(10) |
Jun
(9) |
Jul
(10) |
Aug
(7) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
(3) |
2011 |
Jan
(11) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(4) |
Oct
|
Nov
(6) |
Dec
(9) |
2012 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(3) |
May
(2) |
Jun
|
Jul
(17) |
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
(5) |
2013 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(12) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
2014 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
|
May
|
Jun
(20) |
Jul
(12) |
Aug
(4) |
Sep
(3) |
Oct
(5) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <da...@co...> - 2009-01-30 00:18:22
|
I've been using Simple on a project for several years and I'm finally getting around to upgrading from 3.1.3 to 4.1.1. I'm not finding a replacement for FileEngine in 4.1.1. Any pointers are appreciated. --Dan |
From: <Nia...@ub...> - 2009-01-26 15:18:33
|
Hi, Yes I have renamed Pipeline to Socket for a number of reasons. Anyway Pipeline.java is basically Socket.java now. Also I noticed the UF-8 problem in the file buffer. I have fixed it in 4.1.1 which was released last night. Ill take a look at the build issue. Niall -----Original Message----- From: Christophe Roudet [mailto:cr...@ac...] Sent: 26 January 2009 14:24 To: sim...@li... Subject: [Simpleweb-Support] HTTPS Support Hi, For https support I was doing as in http://svn.sourceforge.net/viewvc/simpleweb/trunk/src/demo/java/org/simp lefr amework/example/Server.java?revision=892&view=markup With a SecureProcessor. With version 4.1 the Pipeline class has disappeared. What it the good way to deal with SSL now? - I think there is a typo in the class FileBuffer: public String encode() throws IOException { return encode("UT-8"); } - And the jar file doesn't include the FileIndexer.properties I have change the build.xml as follows: <jar jarfile="${jar.path}/simple-${version}.jar"> <fileset dir="${build.path}"/> <fileset dir="${source.path}"> <include name="**/*.properties"/> </fileset> </jar> Thanks, Christophe ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Simpleweb-Support mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simpleweb-support Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
From: Christophe R. <cr...@ac...> - 2009-01-26 14:37:00
|
Hi, For https support I was doing as in http://svn.sourceforge.net/viewvc/simpleweb/trunk/src/demo/java/org/simplefr amework/example/Server.java?revision=892&view=markup With a SecureProcessor. With version 4.1 the Pipeline class has disappeared. What it the good way to deal with SSL now? - I think there is a typo in the class FileBuffer: public String encode() throws IOException { return encode("UT-8"); } - And the jar file doesn't include the FileIndexer.properties I have change the build.xml as follows: <jar jarfile="${jar.path}/simple-${version}.jar"> <fileset dir="${build.path}"/> <fileset dir="${source.path}"> <include name="**/*.properties"/> </fileset> </jar> Thanks, Christophe |
From: B. R. <rau...@go...> - 2009-01-13 14:56:02
|
Hi Niall, thanks! Looking at that code did help. I know now how to proceed. Keep up the good work! kind regards, Björn 2009/1/13 <Nia...@ub...>: > Hi, > > Have a look at the following > > http://svn.sourceforge.net/viewvc/simpleweb/trunk/src/test/java/org/simpleframework/http/core/SecurePerformanceTest.java?revision=892 > > I think the SSLContext.getDefault() may be the problem here, however I would have to debug the code to see exactly what is wrong. > > Niall > > -----Original Message----- > From: Björn Raupach [mailto:rau...@go...] > Sent: 13 January 2009 14:35 > To: sim...@li... > Subject: [Simpleweb-Support] https problem > > Dear, > > simple works pretty nice! Thanks a lot! > > For a current project I would like to establish a secure connection via https. I ran into problems. I though it is as easy as: > > Container container = new SomeObject(); > Connection connection = new SocketConnection(container); SocketAddress address = new InetSocketAddress(443); connection.connect(address, SSLContext.getDefault()); > > But the browser doesn't connect. What did I do wrong? > > with kind regards, > Björn > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support > Visit our website at http://www.ubs.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mails are not encrypted and cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The sender > therefore does not accept liability for any errors or omissions in the > contents of this message which arise as a result of e-mail transmission. > If verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities > or related financial instruments. > > UBS Limited is a company registered in England & Wales under company > number 2035362, whose registered office is at 1 Finsbury Avenue, > London, EC2M 2PP, United Kingdom. > > UBS AG (London Branch) is registered as a branch of a foreign company > under number BR004507, whose registered office is at > 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. > > UBS Clearing and Execution Services Limited is a company registered > in England & Wales under company number 03123037, whose registered > office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support > |
From: <Nia...@ub...> - 2009-01-13 14:41:19
|
Hi, Have a look at the following http://svn.sourceforge.net/viewvc/simpleweb/trunk/src/test/java/org/simpleframework/http/core/SecurePerformanceTest.java?revision=892 I think the SSLContext.getDefault() may be the problem here, however I would have to debug the code to see exactly what is wrong. Niall -----Original Message----- From: Björn Raupach [mailto:rau...@go...] Sent: 13 January 2009 14:35 To: sim...@li... Subject: [Simpleweb-Support] https problem Dear, simple works pretty nice! Thanks a lot! For a current project I would like to establish a secure connection via https. I ran into problems. I though it is as easy as: Container container = new SomeObject(); Connection connection = new SocketConnection(container); SocketAddress address = new InetSocketAddress(443); connection.connect(address, SSLContext.getDefault()); But the browser doesn't connect. What did I do wrong? with kind regards, Björn ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Simpleweb-Support mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simpleweb-support Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
From: B. R. <rau...@go...> - 2009-01-13 14:35:20
|
Dear, simple works pretty nice! Thanks a lot! For a current project I would like to establish a secure connection via https. I ran into problems. I though it is as easy as: Container container = new SomeObject(); Connection connection = new SocketConnection(container); SocketAddress address = new InetSocketAddress(443); connection.connect(address, SSLContext.getDefault()); But the browser doesn't connect. What did I do wrong? with kind regards, Björn |
From: Niall G. <gal...@ya...> - 2009-01-08 18:50:33
|
Hi, Yes, only HTTP/1.1 clients will receive chunked responses. So HTTP/1.0 requests with keep alive connections will be connection close, or if Content-Length is specified it will remain keep alive. Niall --- On Thu, 1/8/09, Petite Abeille <pet...@ma...> wrote: > From: Petite Abeille <pet...@ma...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: "Simple support and user issues" <sim...@li...> > Date: Thursday, January 8, 2009, 10:35 AM > On Jan 8, 2009, at 7:16 PM, Niall Gallagher wrote: > > > Also the HTTP/1.0 keep alive fix has been resolved, so > wget will > > work now without needing connection close. > > Do you mean Simple will not send chunked HTTP/1.1 responses > to HTTP/ > 1.0 clients? Or? > > Cheers, > > -- > PA. > http://alt.textdrive.com/nanoki/ > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Petite A. <pet...@ma...> - 2009-01-08 18:35:25
|
On Jan 8, 2009, at 7:16 PM, Niall Gallagher wrote: > Also the HTTP/1.0 keep alive fix has been resolved, so wget will > work now without needing connection close. Do you mean Simple will not send chunked HTTP/1.1 responses to HTTP/ 1.0 clients? Or? Cheers, -- PA. http://alt.textdrive.com/nanoki/ |
From: Niall G. <gal...@ya...> - 2009-01-08 18:16:55
|
Hi, I have released the fix as 4.0.7, which resolves the issue you see with the Ajax viewer with HTTP/1.1 and keep alive connections. This should improve your performance greatly from the connection close semantics you implemented as a work around. Also the HTTP/1.0 keep alive fix has been resolved, so wget will work now without needing connection close. To validate I ran 10,000,000 requests through the server with ApacheBench without a single error, a first for 4.0.x, which makes it now as stable now as the 3.x versions. Thanks for your feedback, its what helps the project keep on improving. Niall --- On Thu, 1/8/09, Niall Gallagher <gal...@ya...> wrote: > From: Niall Gallagher <gal...@ya...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: "Simple support and user issues" <sim...@li...> > Date: Thursday, January 8, 2009, 8:29 AM > Hi, > > The fix is the following, in the class EventDistributor add > the line > > key.attach(event); > > After the line > > key.interestOps(require); > > At approx line 308. This will fix the issue. As a side > note, this has fixed another issue I have been trying to > track down for months. An issue where ApacheBench reports > length errors, I had tried everything and refactored the > transport layer twice, and had written two quite large tools > to analyse the results under high load. For what ever reason > I could never reproduce it. > > Having used Ethereal (Wireshark) and your Ajax viewer I > could reproduce it almost every time I refreshed the browser > window. It showed some requests being responded to twice. > > I will release this fix as well as the HTTP/1.0 keep-alice > issue you observed soon, likely tonight or tomorrow. > > Niall > > > --- On Wed, 1/7/09, Matthias Treydte > <wal...@gm...> wrote: > > > From: Matthias Treydte <wal...@gm...> > > Subject: Re: [Simpleweb-Support] How to handle > HTTP/1.0 clients? > > To: gal...@ya..., "Simple support > and user issues" > <sim...@li...> > > Date: Wednesday, January 7, 2009, 2:34 PM > > Hello Niall, > > > > > Do you still see the issue where content is > getting > > mixed up? If so is it easily reproducable? > > > Id like to investigate this further. > > > > I have sent a mail to your personal address about > this. > > Tanks for your interest! > > > > > > -Matthias > > > > -- > > The secret of life is honesty and fair dealing. If you > can > > fake that, > > you´ve got it made. (Groucho Marx) > > (Please note that according to the German law on data > > retention, > > information on every electronic information exchange > with > > me is > > retained for a period of six months.) > > > ------------------------------------------------------------------------------ > > Check out the new SourceForge.net Marketplace. > > It is the best place to buy or sell services for > > just about anything Open Source. > > http://p.sf.net/sfu/Xq1LFB > > _______________________________________________ > > Simpleweb-Support mailing list > > Sim...@li... > > > https://lists.sourceforge.net/lists/listinfo/simpleweb-support > > > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Niall G. <gal...@ya...> - 2009-01-08 16:29:15
|
Hi, The fix is the following, in the class EventDistributor add the line key.attach(event); After the line key.interestOps(require); At approx line 308. This will fix the issue. As a side note, this has fixed another issue I have been trying to track down for months. An issue where ApacheBench reports length errors, I had tried everything and refactored the transport layer twice, and had written two quite large tools to analyse the results under high load. For what ever reason I could never reproduce it. Having used Ethereal (Wireshark) and your Ajax viewer I could reproduce it almost every time I refreshed the browser window. It showed some requests being responded to twice. I will release this fix as well as the HTTP/1.0 keep-alice issue you observed soon, likely tonight or tomorrow. Niall --- On Wed, 1/7/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Wednesday, January 7, 2009, 2:34 PM > Hello Niall, > > > Do you still see the issue where content is getting > mixed up? If so is it easily reproducable? > > Id like to investigate this further. > > I have sent a mail to your personal address about this. > Tanks for your interest! > > > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-07 22:34:53
|
Hello Niall, > Do you still see the issue where content is getting mixed up? If so is it easily reproducable? > Id like to investigate this further. I have sent a mail to your personal address about this. Tanks for your interest! -Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-07 16:03:18
|
Hi Matthias, Do you still see the issue where content is getting mixed up? If so is it easily reproducable? Id like to investigate this further. Thanks, Niall --- On Tue, 1/6/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Tuesday, January 6, 2009, 3:21 AM > > Is there any use case in particular that highlights the > issue? I will investigate this in > > depth if there is an easily reproducable scenario. > > Currently there is not that much code involved in the > project, as it's > in a proof-of-concept state at the moment. I could mail the > whole > thing to you if you're really willing to take the time > to have a look > at it. There are only 2 classes doing > "interesting" stuff, alltogether > ~500 lines of code. > > > Thank you very much for you support, > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Niall G. <gal...@ya...> - 2009-01-06 16:07:39
|
Hi, Just to clarify, what version of Simple are you using? If you are using 2.0.6 I have a tool that you can run to analyse the response behaviour of the server. I will require you to check out the source tree and build the tool, but it can verify the output very well. If you are interested in using this let me know and ill provide some instructions on how to build, configure and use it. Niall --- On Tue, 1/6/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Tuesday, January 6, 2009, 3:21 AM > > Is there any use case in particular that highlights the > issue? I will investigate this in > > depth if there is an easily reproducable scenario. > > Currently there is not that much code involved in the > project, as it's > in a proof-of-concept state at the moment. I could mail the > whole > thing to you if you're really willing to take the time > to have a look > at it. There are only 2 classes doing > "interesting" stuff, alltogether > ~500 lines of code. > > > Thank you very much for you support, > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-06 11:29:02
|
> Is there any use case in particular that highlights the issue? I will investigate this in > depth if there is an easily reproducable scenario. Currently there is not that much code involved in the project, as it's in a proof-of-concept state at the moment. I could mail the whole thing to you if you're really willing to take the time to have a look at it. There are only 2 classes doing "interesting" stuff, alltogether ~500 lines of code. Thank you very much for you support, -Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-06 11:26:34
|
Hi, If this can easily reproduce the problem, and you don't mind, then that would be great. Thanks, Niall --- On Tue, 1/6/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Tuesday, January 6, 2009, 3:21 AM > > Is there any use case in particular that highlights the > issue? I will investigate this in > > depth if there is an easily reproducable scenario. > > Currently there is not that much code involved in the > project, as it's > in a proof-of-concept state at the moment. I could mail the > whole > thing to you if you're really willing to take the time > to have a look > at it. There are only 2 classes doing > "interesting" stuff, alltogether > ~500 lines of code. > > > Thank you very much for you support, > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-06 10:59:57
|
Hi, Is there any use case in particular that highlights the issue? I will investigate this in depth if there is an easily reproducable scenario. Also, there is reuse of ByteBuffers internal to the transport, ill take a quick look at this to see if this could be an issue. Thanks for the feedback, Niall --- On Tue, 1/6/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Tuesday, January 6, 2009, 2:53 AM > > Just curious, as to what you mean by the following. Is > this a performance issue. If so then this is because > > pipelining will not work with the connection close. > > >> Although there's still a dull feeling, this > gives > >> me time to look at it when time permits. > > Thanks for your interest. I'm building something that > is kind of a web > (ajax...) based remote desktop viewer application atop your > web > server. This means the image to view is cut into numerous > tiles, jpeg > encoded and shown in a table on the client side. The client > uses > asynchronous requests to poll the server which tiles need > to be > updated, and does so. > > So, there are basically > > * the tiles itself. They are held in memory (in encoded > form) and > delivered like this: > > > public void sendImage(Request req, Response resp) > throws Exception { > > resp.addDate("Date", > System.currentTimeMillis()); > > resp.add("Content-Type", > Monitor.IMAGE_MIME_TYPE); > > resp.add("Cache-Control", > "no-store"); > > > > if (buffer == null) updateBuffer(); > > > > ByteBuffer b = buffer.slice(); > > resp.setContentLength(b.limit()); > > final WritableByteChannel c = > resp.getByteChannel(); > > while (b.hasRemaining()) c.write(b); > > c.close(); > > } > > This is an instance method of the "Tile" class, > and the request > parameters are used to determine the tile on which to call > this > method. The only noteworthy thing about this is that the > updateBuffer() Method might block for a short period while > when trying > to acquire read access to the frame buffer which holds the > contents to > show to the client. I do not spawn a new thread in that > case because > this typically takes only a few microseconds. > > The rest of the system (so far) is even simpler, at least > w.r.t. the > usage of the Simple framework: Using the response's > PrintWriter to > throw together the html table, assembling the list of > updated tiles, > delivering two or three static files, nothing fancy. > > > Buffering the content will probably give much better > performance. And using HTTP/1.1 without > > the "Connection: close" header will be the > fastest. I think you will find very few clients use > HTTP/1.0. > > The only time critical part of my application is the > delivery of the > tiles. And as you can from the code snippet above, I set > the content > length on the response, so I expected no problems here. > > However, when it comes to running the whole thing, it > quickly gets a > complete mess up: It starts with wrong tiles being > delivered to the > client, Sometimes refreshing the HTML table (hitting > browser refresh > button) does not load the table, but shows a single tile, > and finally > it gets completely funny: the browser window shows a wild > mix-up of > peices of html code, jpeg image data, http response > headers. This is > true for every browser (ff, ie, konqueror) _except_ opera, > which "just > worked" (tm). > > However, adding the > > > response.set("Connection", > "close") > > before sending out the responses made all the trouble > vanish. It works > in every browser I tried. And the performance is really > stunning, I > it's sufficient for watching videos in 800x600 (at > least on a local > network, it hogs lots of bandwidth. :-) ). I already > started looking > at what's going on with wireshark, but I'm not very > experienced with > that tool and could not spot the problem at first try. > > Without deeper insight, my first guess would be that you > are reusing > NIO ByteBuffers somewhere in the heart of Simple, and these > get messed > up. Possibly I am the first to come up with this problem > because I'm > doing something unusual/illegal with you api. But then: I > have been > stumbling through the code for days now, and it really is > not *that* > complicated. This, plus the face that just adding the > Connection-close > directive makes me think there might be something broken > with buffer > re-use in Simple? > > > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-06 10:53:47
|
> Just curious, as to what you mean by the following. Is this a performance issue. If so then this is because > pipelining will not work with the connection close. >> Although there's still a dull feeling, this gives >> me time to look at it when time permits. Thanks for your interest. I'm building something that is kind of a web (ajax...) based remote desktop viewer application atop your web server. This means the image to view is cut into numerous tiles, jpeg encoded and shown in a table on the client side. The client uses asynchronous requests to poll the server which tiles need to be updated, and does so. So, there are basically * the tiles itself. They are held in memory (in encoded form) and delivered like this: > public void sendImage(Request req, Response resp) throws Exception { > resp.addDate("Date", System.currentTimeMillis()); > resp.add("Content-Type", Monitor.IMAGE_MIME_TYPE); > resp.add("Cache-Control", "no-store"); > > if (buffer == null) updateBuffer(); > > ByteBuffer b = buffer.slice(); > resp.setContentLength(b.limit()); > final WritableByteChannel c = resp.getByteChannel(); > while (b.hasRemaining()) c.write(b); > c.close(); > } This is an instance method of the "Tile" class, and the request parameters are used to determine the tile on which to call this method. The only noteworthy thing about this is that the updateBuffer() Method might block for a short period while when trying to acquire read access to the frame buffer which holds the contents to show to the client. I do not spawn a new thread in that case because this typically takes only a few microseconds. The rest of the system (so far) is even simpler, at least w.r.t. the usage of the Simple framework: Using the response's PrintWriter to throw together the html table, assembling the list of updated tiles, delivering two or three static files, nothing fancy. > Buffering the content will probably give much better performance. And using HTTP/1.1 without > the "Connection: close" header will be the fastest. I think you will find very few clients use HTTP/1.0. The only time critical part of my application is the delivery of the tiles. And as you can from the code snippet above, I set the content length on the response, so I expected no problems here. However, when it comes to running the whole thing, it quickly gets a complete mess up: It starts with wrong tiles being delivered to the client, Sometimes refreshing the HTML table (hitting browser refresh button) does not load the table, but shows a single tile, and finally it gets completely funny: the browser window shows a wild mix-up of peices of html code, jpeg image data, http response headers. This is true for every browser (ff, ie, konqueror) _except_ opera, which "just worked" (tm). However, adding the > response.set("Connection", "close") before sending out the responses made all the trouble vanish. It works in every browser I tried. And the performance is really stunning, I it's sufficient for watching videos in 800x600 (at least on a local network, it hogs lots of bandwidth. :-) ). I already started looking at what's going on with wireshark, but I'm not very experienced with that tool and could not spot the problem at first try. Without deeper insight, my first guess would be that you are reusing NIO ByteBuffers somewhere in the heart of Simple, and these get messed up. Possibly I am the first to come up with this problem because I'm doing something unusual/illegal with you api. But then: I have been stumbling through the code for days now, and it really is not *that* complicated. This, plus the face that just adding the Connection-close directive makes me think there might be something broken with buffer re-use in Simple? -Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-06 00:10:57
|
Hi, Just curious, as to what you mean by the following. Is this a performance issue. If so then this is because pipelining will not work with the connection close. > Although there's still a dull feeling, this gives > me time to look > at it when time permits. Buffering the content will probably give much better performance. And using HTTP/1.1 without the "Connection: close" header will be the fastest. I think you will find very few clients use HTTP/1.0. Niall --- On Mon, 1/5/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: "Simple support and user issues" <sim...@li...> > Date: Monday, January 5, 2009, 1:42 PM > > Wild guess... the server is returning a chunked > response... which is a > > HTTP/1.1 feature... wget doesn't know what to do > with it as it only > > speaks HTTP/1.0... > > > > Arguably, Simple should only return chunked responses > to >= HTTP/1.1 > > clients... > > I think so, too. Anyway, thanks Niall, throwing some > > > response.set("Connection", > "close"); > > at the relevant sections does not only fix the Hello World > example, > but it also fixed the (seemingly) completely unrelated > "weird" problem > on the original application I'm developing. It's > running rock stable > now. Although there's still a dull feeling, this gives > me time to look > at it when time permits. > > > Thanks again, > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-05 21:52:34
|
> Wild guess... the server is returning a chunked response... which is a > HTTP/1.1 feature... wget doesn't know what to do with it as it only > speaks HTTP/1.0... > > Arguably, Simple should only return chunked responses to >= HTTP/1.1 > clients... I think so, too. Anyway, thanks Niall, throwing some > response.set("Connection", "close"); at the relevant sections does not only fix the Hello World example, but it also fixed the (seemingly) completely unrelated "weird" problem on the original application I'm developing. It's running rock stable now. Although there's still a dull feeling, this gives me time to look at it when time permits. Thanks again, -Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Petite A. <pet...@ma...> - 2009-01-05 19:20:26
|
On Jan 5, 2009, at 3:24 PM, Matthias Treydte wrote: > Transfer-Encoding: chunked > > ...and here wget hangs, after having read 27(!) bytes from the server, > waiting for more (or a connection close, I assume) Wild guess... the server is returning a chunked response... which is a HTTP/1.1 feature... wget doesn't know what to do with it as it only speaks HTTP/1.0... Arguably, Simple should only return chunked responses to >= HTTP/1.1 clients... Cheers, -- PA. http://alt.textdrive.com/nanoki/ |
From: Niall G. <gal...@ya...> - 2009-01-05 16:02:59
|
Hi, I've run this with wget. Perhaps this should use connection close when you do not specify the content length for dynamic content. Anyway if you buffer the output or add the following it works fine with HTTP/1.0. But is not advisable for HTTP/1.1 because it will reduce the performance signifigantly. response.set("Connection", "close"); Niall --- On Mon, 1/5/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: Re: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: gal...@ya..., "Simple support and user issues" <sim...@li...> > Date: Monday, January 5, 2009, 6:24 AM > Hello Nial, > > thanks for the fast response. I toyed around with the > HelloWorld > example a little bit more... Here are my observations: > > First, this is the debugging output for wget running > against the code > provided on simpleframework.org (with added handling of the > not-cought > exception): > > [trem@forest tmp]$ LANG=en_GB wget -d localhost:8080 > DEBUG output created by Wget 1.11.4 (Red Hat modified) on > linux-gnu. > > --2009-01-05 14:43:22-- http://localhost:8080/ > Resolving localhost... 127.0.0.1 > Caching localhost => 127.0.0.1 > Connecting to localhost|127.0.0.1|:8080... connected. > Created socket 3. > Releasing 0x0920e608 (new refcount 1). > > ---request begin--- > GET / HTTP/1.0 > User-Agent: Wget/1.11.4 (Red Hat modified) > Accept: */* > Host: localhost:8080 > Connection: Keep-Alive > > ---request end--- > HTTP request sent, awaiting response... > ---response begin--- > HTTP/1.1 200 OK > Content-Type: text/plain > Connection: keep-alive > Last-Modified: Mon, 05 Jan 2009 13:43:22 GMT > Transfer-Encoding: chunked > Server: HelloWorld/1.0 (Simple 4.0) > Date: Mon, 05 Jan 2009 13:43:22 GMT > > ---response end--- > 200 OK > Length: unspecified [text/plain] > > ...and here wget hangs, after having read 27(!) bytes from > the server, > waiting for more (or a connection close, I assume) > > I also tested the example using the 4.0.0 version of > Simple, with the > same result. I think this is a regression from the 3.x > releases, as > the same thing ported to simple 3.x runs perfectly: > > import java.util.logging.Level; > import java.util.logging.Logger; > import java.net.InetSocketAddress; > import java.net.SocketAddress; > import java.io.PrintStream; > import java.net.ServerSocket; > import simple.http.ProtocolHandler; > import simple.http.Request; > import simple.http.Response; > import simple.http.connect.Connection; > import simple.http.connect.ConnectionFactory; > > public class HelloWorld implements ProtocolHandler { > > public void handle(Request request, Response response) { > PrintStream body = null; > try { > body = response.getPrintStream(); > } catch (Exception ex) { > > Logger.getLogger(HelloWorld.class.getName()).log(Level.SEVERE, > null, ex); > } > > long time = System.currentTimeMillis(); > > response.set("Content-Type", > "text/plain"); > response.set("Server", "HelloWorld/1.0 > (Simple 4.0)"); > response.setDate("Date", time); > response.setDate("Last-Modified", time); > > body.println("Hello World"); > body.close(); > } > > public static void main(String[] list) throws Exception > { > ProtocolHandler ph = new HelloWorld(); > Connection connection = > ConnectionFactory.getConnection(ph); > SocketAddress address = new InetSocketAddress(8080); > > connection.connect(new ServerSocket(8080)); > } > } > > The response header gets equipped with a "Connection: > close" line, and > wget writes 12 bytes to disk and exits. > > Could it really be that the 4.x releases are broken in this > regard? > > BTW: The real reason I'm playing around with this is > much more weird, > and I stumbled upon this issue while trying to find a > minimal example > of my real trouble to post to the list. But I think > I'll start a > different post for that problem once I have the example at > hand... > > > -Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-05 14:24:29
|
Hello Nial, thanks for the fast response. I toyed around with the HelloWorld example a little bit more... Here are my observations: First, this is the debugging output for wget running against the code provided on simpleframework.org (with added handling of the not-cought exception): [trem@forest tmp]$ LANG=en_GB wget -d localhost:8080 DEBUG output created by Wget 1.11.4 (Red Hat modified) on linux-gnu. --2009-01-05 14:43:22-- http://localhost:8080/ Resolving localhost... 127.0.0.1 Caching localhost => 127.0.0.1 Connecting to localhost|127.0.0.1|:8080... connected. Created socket 3. Releasing 0x0920e608 (new refcount 1). ---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.11.4 (Red Hat modified) Accept: */* Host: localhost:8080 Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Content-Type: text/plain Connection: keep-alive Last-Modified: Mon, 05 Jan 2009 13:43:22 GMT Transfer-Encoding: chunked Server: HelloWorld/1.0 (Simple 4.0) Date: Mon, 05 Jan 2009 13:43:22 GMT ---response end--- 200 OK Length: unspecified [text/plain] ...and here wget hangs, after having read 27(!) bytes from the server, waiting for more (or a connection close, I assume) I also tested the example using the 4.0.0 version of Simple, with the same result. I think this is a regression from the 3.x releases, as the same thing ported to simple 3.x runs perfectly: import java.util.logging.Level; import java.util.logging.Logger; import java.net.InetSocketAddress; import java.net.SocketAddress; import java.io.PrintStream; import java.net.ServerSocket; import simple.http.ProtocolHandler; import simple.http.Request; import simple.http.Response; import simple.http.connect.Connection; import simple.http.connect.ConnectionFactory; public class HelloWorld implements ProtocolHandler { public void handle(Request request, Response response) { PrintStream body = null; try { body = response.getPrintStream(); } catch (Exception ex) { Logger.getLogger(HelloWorld.class.getName()).log(Level.SEVERE, null, ex); } long time = System.currentTimeMillis(); response.set("Content-Type", "text/plain"); response.set("Server", "HelloWorld/1.0 (Simple 4.0)"); response.setDate("Date", time); response.setDate("Last-Modified", time); body.println("Hello World"); body.close(); } public static void main(String[] list) throws Exception { ProtocolHandler ph = new HelloWorld(); Connection connection = ConnectionFactory.getConnection(ph); SocketAddress address = new InetSocketAddress(8080); connection.connect(new ServerSocket(8080)); } } The response header gets equipped with a "Connection: close" line, and wget writes 12 bytes to disk and exits. Could it really be that the 4.x releases are broken in this regard? BTW: The real reason I'm playing around with this is much more weird, and I stumbled upon this issue while trying to find a minimal example of my real trouble to post to the list. But I think I'll start a different post for that problem once I have the example at hand... -Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-05 13:35:18
|
Hi, This seems strange, don't know if the wget client is expecting a connection close? Simple will handle HTTP versions correctly, not sure what wget is expecting. Anyway, what you can do to ensure a Content-Length header is to buffer the output. Do the following. PrintStream body = response.getPrintStream(8192); Then write to the stream. When it is finished close the print stream and the buffered response will be written with the correct content length. If this does not work send me the code you are using, ill take a look. Niall --- On Mon, 1/5/09, Matthias Treydte <wal...@gm...> wrote: > From: Matthias Treydte <wal...@gm...> > Subject: [Simpleweb-Support] How to handle HTTP/1.0 clients? > To: sim...@li... > Date: Monday, January 5, 2009, 3:24 AM > Hello, > > I'm playing around with the simple framework (4.0.6) > and have problems > with the HelloWorld example on simpleframework.org: > > First thing is: The example does not compile, as the > response.getPrintStream() method is declared to "throw > Exception", > which is not caught. I worked around this by surrounding > the offending > statement with try/catch, so the first line of the handle > method > becomes: > > PrintStream body = null; > try { > body = response.getPrintStream(); > } catch (Exception ex) { > > Logger.getLogger(HelloWorld.class.getName()).log(Level.SEVERE, > null, ex); > } > > Now I can compile/run the example. However, If I point wget > to > localhost:8080, it just hangs. This makes sense, as the > response is > sent using "chunked" transfer encoding, which is > not supported by 1.0 > clients afaik. Reading the JavaDoc of the > setContentLength(...) method > of Response makes me *think* this case is already handled > by the > framework. But as it seems, I'm wrong about that. > > Anyone can help me with that? > > > Thanks in advance, > Matthias > > -- > The secret of life is honesty and fair dealing. If you can > fake that, > you´ve got it made. (Groucho Marx) > (Please note that according to the German law on data > retention, > information on every electronic information exchange with > me is > retained for a period of six months.) > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |
From: Matthias T. <wal...@gm...> - 2009-01-05 11:24:25
|
Hello, I'm playing around with the simple framework (4.0.6) and have problems with the HelloWorld example on simpleframework.org: First thing is: The example does not compile, as the response.getPrintStream() method is declared to "throw Exception", which is not caught. I worked around this by surrounding the offending statement with try/catch, so the first line of the handle method becomes: PrintStream body = null; try { body = response.getPrintStream(); } catch (Exception ex) { Logger.getLogger(HelloWorld.class.getName()).log(Level.SEVERE, null, ex); } Now I can compile/run the example. However, If I point wget to localhost:8080, it just hangs. This makes sense, as the response is sent using "chunked" transfer encoding, which is not supported by 1.0 clients afaik. Reading the JavaDoc of the setContentLength(...) method of Response makes me *think* this case is already handled by the framework. But as it seems, I'm wrong about that. Anyone can help me with that? Thanks in advance, Matthias -- The secret of life is honesty and fair dealing. If you can fake that, you´ve got it made. (Groucho Marx) (Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.) |
From: Niall G. <gal...@ya...> - 2009-01-03 14:43:39
|
Hi, Can you provide the thread dump? With this I can tell whats happening. Set the thread dumper thread to daemon and do _not_ kill it. To start the thread dumper do this. ThreadDumper dumper = new ThreadDumper(5000); threadDumper.setDaemon(true); threadDumper.start(); Remove the line from your code. threadDumper.kill(); Once started leave it running. If your process does not stop then provide the thread dump it generates every five seconds. Niall --- On Fri, 1/2/09, lyo <liy...@ho...> wrote: > From: lyo <liy...@ho...> > Subject: Re: [Simpleweb-Support] hello,please help me! (sourceforge form) > To: gal...@ya..., sim...@li... > Date: Friday, January 2, 2009, 7:07 PM > Hi friends: > > I do it by using ThreadDumper.java(in the dir: > simple-4.0.6\test\src\org\simpleframework\http\core).But > the server thread remain not shutdown immediately.I means > there is an javaw.exe in my windows process.My code is: > //////////////////// java code ////////////////// > public class TestSimpleServer implements Container { > > private static final Log log = > LogFactory.getLog(TestSimpleServer.class); > static ContainerServer processor =null; > static Connection connection = null; > static Server server = null; > static private ThreadDumper threadDumper; > > /** > * @param args > */ > public static void main(String[] args)throws Exception { > // TODO Auto-generated method stub > Container container = new TestSimpleServer(); > server = new ContainerServer(container, 10);//what does > the 10 mean? my server should be connected by 1000 clients. > connection = new SocketConnection(server); > SocketAddress address = new InetSocketAddress(8080); > connection.connect(address); > threadDumper = new ThreadDumper(60000); // dump threads > every minute > threadDumper.start(); > > > } > > public void handle(Request arg0, Response response) { > > log.info("### Enter hendle"); > String param; > try { > param = arg0.getParameter("id"); > log.info(">>> param:"+param); > if("s".equals(param)){ // if > client send parameter "s",then the server > shutdown! > connection.close(); > server.stop(); > threadDumper.kill(); > }else{ > PrintStream body=null; > body = response.getPrintStream(); > long time = System.currentTimeMillis(); > > response.set("Content-Type", > "text/html"); > response.set("Server", > "HelloWorld/1.0 (Simple 4.0)"); > response.setDate("Date", time); > response.setDate("Last-Modified", > time); > > body.println("<font > color='red'>Test it</font>"); > body.close(); > > } > } catch (Exception e) { > e.printStackTrace(); > } > > } > > > } > > > ///////////////// end //////////////////////// > I don't want to keep an javaw.exe in my windows process > :( . So what should I do?Thks! > ----- Original Message ----- > From: lyo > To: gal...@ya... ; > sim...@li... > Sent: Saturday, January 03, 2009 2:37 AM > Subject: hello,please help me! (sourceforge form) > > > hello: > > I don't know how to reply this > thread:http://sourceforge.net/mailarchive/message.php?msg_name=266712.48202.qm%40web36702.mail.mud.yahoo.com > So I send this email to you. I stop server in your way: > /////////////// java code ////////////////// > Container container = new TestSimpleServer(); > Server server = new ContainerServer(container, 10); > Connection connection = new SocketConnection(server); > SocketAddress address = new InetSocketAddress(8080); > > connection.connect(address); > connection.close(); > server.stop(); > > /////////////////////////////////////////// > > but the server throws Exception: > //////////////////////////////////////////////// > java.nio.channels.ClosedChannelException > at > sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:130) > at > org.simpleframework.http.connect.Acceptor.accept(Acceptor.java:147) > at > org.simpleframework.http.connect.Acceptor.run(Acceptor.java:104) > at > org.simpleframework.util.select.SelectEvent.run(SelectEvent.java:74) > at > org.simpleframework.util.thread.DirectExecutor.execute(DirectExecutor.java:43) > at > org.simpleframework.util.select.EventDistributor.process(EventDistributor.java:386) > at > org.simpleframework.util.select.EventDistributor.process(EventDistributor.java:365) > at > org.simpleframework.util.select.EventDistributor.distribute(EventDistributor.java:342) > at > org.simpleframework.util.select.EventDistributor.run(EventDistributor.java:150) > ////////////////////////////////////////////////// > And the server don't stop. What should I do? > ------------------------------------------------------------------------------ > _______________________________________________ > Simpleweb-Support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simpleweb-support |