Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19710 > unrolled thread

Java daemon

Back to article view | Back to comp.lang.java.programmer

Contents

  Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 22:17 +0800
    Re: Java daemon David Lamb <dalamb@cs.queensu.ca> - 2012-11-12 09:25 -0500
      Re: Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 23:55 +0800
        Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-12 22:07 +0000
          Re: Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-13 10:56 +0800
            Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:08 -0500
            Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 13:59 +0800
            Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-13 21:50 +0000
              Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:43 -0500
                Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-19 01:05 +0000
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 20:41 -0500
                    Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-20 00:32 +0000
                      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 20:07 -0500
                    Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-19 20:38 -0400
                      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 20:22 -0500
                        Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-20 17:46 -0400
                Re: Java daemon Lew <lewbloch@gmail.com> - 2012-11-18 20:10 -0800
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 10:50 -0500
          Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:06 -0500
            Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-13 21:36 +0000
              Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-13 17:31 -0500
                Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-14 21:33 +0000
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-14 16:55 -0500
                    Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-15 02:09 +0000
      Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 14:40 +0800
        Re: Java daemon Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-11-12 23:39 -0800
          Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 16:16 +0800
        Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-13 06:37 -0400
        Re: Java daemon David Lamb <dalamb@cs.queensu.ca> - 2012-11-13 08:46 -0500
        Re: Java daemon "John B. Matthews" <nospam@nospam.invalid> - 2012-11-13 21:23 -0500
        Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:52 -0500
        Re: Java daemon markspace <-@.> - 2012-11-18 14:02 -0800
          Re: Java daemon jlp <jlp@jlp.com> - 2012-11-19 20:39 +0100
            Re: Java daemon "SL@maxis" <ecp_gen@my-rialto.com> - 2012-11-20 15:23 +0800
    Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 09:41 -0500
    Re: Java daemon Jim Janney <jjanney@shell.xmission.com> - 2012-11-12 14:24 -0700
      Re: Java daemon Lew <lewbloch@gmail.com> - 2012-11-12 13:35 -0800
        Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:05 -0500
      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:40 -0500

Page 1 of 2  [1] 2  Next page →

#19710 — Java daemon

I gather that PHP daemon suffers from memory leak problem due to its garbage 
collector mechanism.

Since java also adopts the garbage collector mechanism, would java daemon 
suffers from the same memory problem ?

Thanks. 

[toc] | [next] | [standalone]

#19711

On 12/11/2012 9:17 AM, sl@exabyte wrote:
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?

There are several different ways to do garbage collection, so flaws in 
one implementation have no bearing on what goes on with another.

The most common complaint that crosses implementations is the 
unpredictability of when a gc happens, which can be a problem for a 
program with serious real-time constraints. IIRC Java implementations 
often have the gc run continuously and incrementally in a separate 
thread, which evens out the effect.

[toc] | [prev] | [next] | [standalone]

#19713

David Lamb wrote:
> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>
> The most common complaint that crosses implementations is the
> unpredictability of when a gc happens, which can be a problem for a
> program with serious real-time constraints. IIRC Java implementations
> often have the gc run continuously and incrementally in a separate
> thread, which evens out the effect.

This is an interesting pointer/direction (I am new with java, but have done 
quite some C/C++ on windows).

I have sort of given up hope on PHP daemon; one cannot touch its GC I 
suppose. I am adamant to go C/C++; I have not done anything on Linux. I 
suppose it would take too long a time to get it up and running (my target is 
end of December 2012). So my next best option is java.

[toc] | [prev] | [next] | [standalone]

#19720

On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:

> I have sort of given up hope on PHP daemon; one cannot touch its GC I
> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>
I've not done a lot with PHP, but haven't (so far) run into any 
particular problems with the Apache/PHP combination under Linux.

> I suppose it would take too long a time to get it up and running (my
> target is end of December 2012). So my next best option is java.
>
Actual Linux installation is fairly fast: the last install I did (RedHat 
Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about the 
following times:

- 1.5 hours to d/l and burn a 3.6GB DVD ISO image, though the time it
  takes depends on your broadband speed.

- around an hour for the actual install. Exactly how long this takes
  depends on how much you customize the disk partitioning and the list
  of packages you ant to install. If you select 'all packages' and
  use two partitions (30 GB for root and the rest of the disk for /home)
  you should complete the install in just under an hour.

- 1.5 hours to update all packages that changed since the ISO image was
  built - partly dependent on broadband speed.

That should leave you with an installation that contains, among other 
useful stuff,  Apache, PHP, Python, Perl, C, C++, Open Java, PostgreSQL, 
Mysql and Eclipse. 

If you're happiest with a Windows-like desktop, specify XFCE as your 
desktop. Additional configuration should be minimal. Apache and the 
various languages and databases should run if you enable their daemons 
because their default Fedora configurations are fairly sensible - thats 
Apache and any databases you need. All the other essential daemons will 
be enabled by default, including the firewall and the SELinux security 
module.

If you're familiar with Unices at all, you should be off and running PDQ. 
There's a good graphical editor (gedit) as well as vi and emacs.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19726

Martin Gregorie wrote:
>>
> Actual Linux installation is fairly fast: the last install I did
> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
> the following times:
>
>....

Acutally I mean the my c/c++ programming in Linux would probably take too 
long a time to meet my target since I have done anything on Linux.
My server program has to process XML string and MySQL. I had a look at a 
sample C program with MySQL API last night, it did not look that 
intimidating. At this stage I am a bit encouraged to dip my little toe into 
the Linux pool. But my programming experience tells me there are always 
surprises. :-)

[toc] | [prev] | [next] | [standalone]

#19729

On 11/12/2012 9:56 PM, sl@exabyte wrote:
> Martin Gregorie wrote:
>>>
>> Actual Linux installation is fairly fast: the last install I did
>> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
>> the following times:
>>
>> ....
>
> Acutally I mean the my c/c++ programming in Linux would probably take too
> long a time to meet my target since I have done anything on Linux.
> My server program has to process XML string and MySQL. I had a look at a
> sample C program with MySQL API last night, it did not look that
> intimidating. At this stage I am a bit encouraged to dip my little toe into
> the Linux pool. But my programming experience tells me there are always
> surprises. :-)

The MySQL C API is indeed rather easy to work with.

If you have worked with PHP nysql or mysqli extensions, then it
will be even easier.

Arne

[toc] | [prev] | [next] | [standalone]

#19731

sl@exabyte wrote:

> Acutally I mean the my c/c++ programming in Linux would probably take
> too long a time to meet my target since I have done anything on Linux.
> My server program has to process XML string and MySQL. I had a look
> at a sample C program with MySQL API last night, it did not look that
> intimidating. At this stage I am a bit encouraged to dip my little
> toe into the Linux pool. But my programming experience tells me there
> are always surprises. :-)

A correction, the statement "...since I have done anything on Linux" should 
read "...since I have not done anything on Linux". 

[toc] | [prev] | [next] | [standalone]

#19742

On Tue, 13 Nov 2012 10:56:47 +0800, sl@exabyte wrote:

> Martin Gregorie wrote:
>>>
>> Actual Linux installation is fairly fast: the last install I did
>> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
>> the following times:
>>
>>....
> 
> Acutally I mean the my c/c++ programming in Linux would probably take
> too long a time to meet my target since I have done anything on Linux.
>
So don't use them. 

You'd have PHP (which you say you already know) and Apache, so move your 
web pages and PHP scripts over and get hacking. The PEAR library is alive 
and well under Linux too, so all the standard PHP add-ons, database 
interfaces, etc. are there to be used.

> My server program has to process XML string and MySQL.
>
PHP can deal with XML and interface to MySQL, though why anybody would 
use it when using PostgreSQL has more standardised SQL and is as easy to 
install for the same price, is more than I can imagine.

If you don't have O'Reilly's "Programming PHP" in your library, maybe you 
need a copy.


If, for some reason, you can't do everything you need with Apache, PHP 
and PostgreSQL, most distros have Python, Perl and gawk awaiting your 
pleasure.

Fedora has the Java OpenJDK 1.7 too.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19794

On 11/13/2012 4:50 PM, Martin Gregorie wrote:
> On Tue, 13 Nov 2012 10:56:47 +0800, sl@exabyte wrote:
>> My server program has to process XML string and MySQL.
>>
> PHP can deal with XML and interface to MySQL, though why anybody would
> use it when using PostgreSQL has more standardised SQL and is as easy to
> install for the same price, is more than I can imagine.

More users => better support.

And most of the non-standard SQL problems went away with
MySQL 4.1 and 5.0 back in 2005 and 2006.

Arne

[toc] | [prev] | [next] | [standalone]

#19799

On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:

> And most of the non-standard SQL problems went away with MySQL 4.1 and
> 5.0 back in 2005 and 2006.
> 
So, you're telling me its now ditched auto-incrementing fields and has 
implemented sequences?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19800

On 11/18/2012 8:05 PM, Martin Gregorie wrote:
> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>> 5.0 back in 2005 and 2006.
>>
> So, you're telling me its now ditched auto-incrementing fields and has
> implemented sequences?

No.

But then auto increment is also the standard (with IDENTITY
keyword though).

And it is also the most widely supported: MySQL,
SQLServer, DB2 etc..

PostgreSQL has it in the form of SERIAL (even though it is just
syntactic sugar for a sequence).

Sequences is really an Oracle and PostgreSQL proprietary thing.

MySQL are trying to converge towards standards not away from
standards.

Arne

[toc] | [prev] | [next] | [standalone]

#19820

On Sun, 18 Nov 2012 20:41:19 -0500, Arne Vajhøj wrote:

> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>> 5.0 back in 2005 and 2006.
>>>
>> So, you're telling me its now ditched auto-incrementing fields and has
>> implemented sequences?
> 
> No.
> 
> But then auto increment is also the standard (with IDENTITY keyword
> though).
> 
> And it is also the most widely supported: MySQL,
> SQLServer, DB2 etc..
> 
> PostgreSQL has it in the form of SERIAL (even though it is just
> syntactic sugar for a sequence).
> 
> Sequences is really an Oracle and PostgreSQL proprietary thing.
>
I haven't looked at the SQL standard for quite a while and thought 
sequences were in it. My bad.
  
I have to say I like sequences a lot better than auto-incrementing fields 
for one reason: you know what the unique value is before doing the 
INSERT, which seems cleaner to me that doing the INSERT and then reading 
the new row to find out what the auto-incremented value is. 

In fact, for this exact reason I'd prefer do what I've had to do with 
DBMSs that don't have either sequences of auto-incrementing: namely to 
'fake' a sequence by updating a singleton row in a dedicated table rather 
than use auto-increment. 

Needless to say, this should also happen within an explicit commitment 
unit and, of course, ymmv.
 
> MySQL are trying to converge towards standards not away from standards.
>
I'm pleased to hear it: SQL standards are A Good Thing.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19822

On 11/19/2012 7:32 PM, Martin Gregorie wrote:
> On Sun, 18 Nov 2012 20:41:19 -0500, Arne Vajhøj wrote:
>
>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>> 5.0 back in 2005 and 2006.
>>>>
>>> So, you're telling me its now ditched auto-incrementing fields and has
>>> implemented sequences?
>>
>> No.
>>
>> But then auto increment is also the standard (with IDENTITY keyword
>> though).
>>
>> And it is also the most widely supported: MySQL,
>> SQLServer, DB2 etc..
>>
>> PostgreSQL has it in the form of SERIAL (even though it is just
>> syntactic sugar for a sequence).
>>
>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>>
> I haven't looked at the SQL standard for quite a while and thought
> sequences were in it. My bad.
>
> I have to say I like sequences a lot better than auto-incrementing fields
> for one reason: you know what the unique value is before doing the
> INSERT, which seems cleaner to me that doing the INSERT and then reading
> the new row to find out what the auto-incremented value is.

You don't read the row to find out what the generated key is.

You query the connection for what it is.

The function name is database specific, but JDBC encapsulate
it nicely via Statement getGeneratedKeys.

Arne

[toc] | [prev] | [next] | [standalone]

#19821

On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>> 5.0 back in 2005 and 2006.
>>>
>> So, you're telling me its now ditched auto-incrementing fields and has
>> implemented sequences?
>
> No.
>
> But then auto increment is also the standard (with IDENTITY
> keyword though).
>
> And it is also the most widely supported: MySQL,
> SQLServer, DB2 etc..

Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences 
(now), DB2 has sequences...MySQL, I don't think so (I stand to be 
corrected).

> PostgreSQL has it in the form of SERIAL (even though it is just
> syntactic sugar for a sequence).
>
> Sequences is really an Oracle and PostgreSQL proprietary thing.

Not anymore. Sequences were introduced into the SQL standard in 2003. As 
you alluded to above, this version introduced identity columns (which 
are considered to use an internal sequence generator).

> MySQL are trying to converge towards standards not away from
> standards.

No more so than anyone else.

> Arne

AHS

[toc] | [prev] | [next] | [standalone]

#19823

On 11/19/2012 7:38 PM, Arved Sandstrom wrote:
> On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>> 5.0 back in 2005 and 2006.
>>>>
>>> So, you're telling me its now ditched auto-incrementing fields and has
>>> implemented sequences?
>>
>> No.
>>
>> But then auto increment is also the standard (with IDENTITY
>> keyword though).
>>
>> And it is also the most widely supported: MySQL,
>> SQLServer, DB2 etc..
>
> Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences
> (now),

In 2012. They have had identity auto increment since it was called
Sybase.

>       DB2 has sequences...MySQL, I don't think so (I stand to be
> corrected).
>
>> PostgreSQL has it in the form of SERIAL (even though it is just
>> syntactic sugar for a sequence).
>>
>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>
> Not anymore. Sequences were introduced into the SQL standard in 2003. As
> you alluded to above, this version introduced identity columns (which
> are considered to use an internal sequence generator).

????

SQL IDENTITY columns are used the same way as MySQL auto increment
not the same way as sequences in Oracle and PostgreSQL.

There must be something like a sequence behind it. But if it is not
visible and the usage is restricted to the auto increment way, then
that is implementation.

Arne

[toc] | [prev] | [next] | [standalone]

#19830

On 11/19/2012 09:22 PM, Arne Vajhøj wrote:
> On 11/19/2012 7:38 PM, Arved Sandstrom wrote:
>> On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
>>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>>> 5.0 back in 2005 and 2006.
>>>>>
>>>> So, you're telling me its now ditched auto-incrementing fields and has
>>>> implemented sequences?
>>>
>>> No.
>>>
>>> But then auto increment is also the standard (with IDENTITY
>>> keyword though).
>>>
>>> And it is also the most widely supported: MySQL,
>>> SQLServer, DB2 etc..
>>
>> Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences
>> (now),
>
> In 2012. They have had identity auto increment since it was called
> Sybase.

Hence my "(now)".

>>       DB2 has sequences...MySQL, I don't think so (I stand to be
>> corrected).
>>
>>> PostgreSQL has it in the form of SERIAL (even though it is just
>>> syntactic sugar for a sequence).
>>>
>>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>>
>> Not anymore. Sequences were introduced into the SQL standard in 2003. As
>> you alluded to above, this version introduced identity columns (which
>> are considered to use an internal sequence generator).
>
> ????
>
> SQL IDENTITY columns are used the same way as MySQL auto increment
> not the same way as sequences in Oracle and PostgreSQL.
>
> There must be something like a sequence behind it. But if it is not
> visible and the usage is restricted to the auto increment way, then
> that is implementation.
>
> Arne
>
Hence my wording "are considered to". IOW, the spec says that for 
definitional purposes, identity columns are associated with an internal 
sequence generator.

But it's separate from implementation details - the "notion" of an 
internal sequence generator ("notion" being a word used in the spec) is 
inherent in the definition of identity columns in the *specification*. 
It is simply a useful abstraction, especially seeing as how sequences 
were introduced in the same spec. There are both external SGs (the ones 
we can create and configure) and internal SGs, the latter being 
components of another schema object.

I think we all understand the difference between IDENTITY and (external) 
sequences (the latter a la PostgreSQL or Oracle). One is inextricably 
associated with a specific table, one is not.

AHS

[toc] | [prev] | [next] | [standalone]

#19804

Arne Vajhøj wrote:
> And most of the non-standard SQL problems went away with
> MySQL 4.1 and 5.0 back in 2005 and 2006.

TIMESTAMP remains non-standard.
http://dev.mysql.com/doc/refman/5.5/en/datetime.html
http://dev.mysql.com/doc/refman/5.5/en/timestamp-initialization.html

I am aware of no perfectly compliant SQL DBMS.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19815

On 11/18/2012 11:10 PM, Lew wrote:
> Arne Vajhøj wrote:
>> And most of the non-standard SQL problems went away with
>> MySQL 4.1 and 5.0 back in 2005 and 2006.
>
> TIMESTAMP remains non-standard.
> http://dev.mysql.com/doc/refman/5.5/en/datetime.html
> http://dev.mysql.com/doc/refman/5.5/en/timestamp-initialization.html

Note that the closest to SQL TIMESTAMP is not MySQL TIMESTAMP
but MySQL DATETIME.

(the difference between standard and DATETIME is that DATETIME is
missing the fractional seconds and TZ)

> I am aware of no perfectly compliant SQL DBMS.

True.

But some stuff are worse than other.

Very old versions of MySQL was pretty bad. UNION was
added in 4.0, subqueries was added in 4.1 and views
was added in 5.0.

Arne

[toc] | [prev] | [next] | [standalone]

#19728

On 11/12/2012 5:07 PM, Martin Gregorie wrote:
> On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:
>> I have sort of given up hope on PHP daemon; one cannot touch its GC I
>> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>>
> I've not done a lot with PHP, but haven't (so far) run into any
> particular problems with the Apache/PHP combination under Linux.

For the typical web page the request scope is sufficient to
avoid problems.

But a daemon is not a typical web page.

Arne

[toc] | [prev] | [next] | [standalone]

#19741

On Mon, 12 Nov 2012 22:06:50 -0500, Arne Vajhøj wrote:

> On 11/12/2012 5:07 PM, Martin Gregorie wrote:
>> On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:
>>> I have sort of given up hope on PHP daemon; one cannot touch its GC I
>>> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>>>
>> I've not done a lot with PHP, but haven't (so far) run into any
>> particular problems with the Apache/PHP combination under Linux.
> 
> For the typical web page the request scope is sufficient to avoid
> problems.
> 
> But a daemon is not a typical web page.
>
I've been picking it up from "Programming PHP" (O'Reilly). That doesn't 
mention anything even vaguely resembling a PHP Daemon. 

What is it? 
If you have Apache, why would you need it? 
Is it some sort of lightweight web server?
    

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web