Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » SCGI Class
Re: SCGI Class [message #31769 is a reply to message #31766] Fri, 25 March 2011 22:55 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.
Re: SCGI Class [message #31774 is a reply to message #31769] Fri, 25 March 2011 23:56 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
zsolt wrote on Fri, 25 March 2011 17:55

BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.


Actually, I would guess that on that much traffic, you simply run out of TCP/IP per port limit... (which is in thousands per second max).
Re: SCGI Class [message #31778 is a reply to message #31769] Sat, 26 March 2011 23:00 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

zsolt wrote on Sat, 26 March 2011 00:55

BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.

What if in the main cycle the the newly created client socket is processed in another thread while server socket is free to accept more connections?
while (run)
{ if  (serverSocket.Accept(&clientSocket)
  {
    GetThreadFromPoolAndProcess(clientSocket);
  }
}

[Updated on: Sat, 26 March 2011 23:47]

Report message to a moderator

Re: SCGI Class [message #31779 is a reply to message #31778] Sun, 27 March 2011 06:54 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
Mindtraveller wrote on Sat, 26 March 2011 23:00

What if in the main cycle the the newly created client socket is processed in another thread while server socket is free to accept more connections?
while (run)
{ if  (serverSocket.Accept(&clientSocket)
  {
    GetThreadFromPoolAndProcess(clientSocket);
  }
}



That seems like the logical way.
My Upp apps as clients interact with Java apps/server.
New thread/socket for each client.

	// The body of the server thread. Loop forever, listening for and
	// accepting connections from clients. For each connection,
	// create a Connection object to handle communication through the
	// new Socket.
	public void run() {
		try {
			while (true) {
				Socket client_socket = listen_socket.accept();
				Connection c = new Connection(client_socket);
			}
		} catch (IOException e) {
			fail(e, "Exception while listening for connections");
		}
	}
}


I did not write the server code but just followed an example.

Neil

[Updated on: Sun, 27 March 2011 07:15]

Report message to a moderator

Re: SCGI Class [message #31780 is a reply to message #31779] Sun, 27 March 2011 09:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, I guess that in that case it would likely made sense to break Run into smaller parts, just like it is done with XmlRpc, so that client code could arrange any complicated usage scenario it wishes...
Re: SCGI Class [message #31781 is a reply to message #31778] Sun, 27 March 2011 10:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Sat, 26 March 2011 18:00

zsolt wrote on Sat, 26 March 2011 00:55

BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.

What if in the main cycle the the newly created client socket is processed in another thread while server socket is free to accept more connections?
while (run)
{ if  (serverSocket.Accept(&clientSocket)
  {
    GetThreadFromPoolAndProcess(clientSocket);
  }
}



Actually, this can be quite nicely with something like

while(run) 
{ if  (serverSocket.Accept(&clientSocket) {
     DoWork();
  }
}


and then simply starting several threads to run this loop (with single clientSocket). As accept is reentrant and MT safe, it would return only for single thread running, thus managing the thread pool.
Re: SCGI Class [message #31787 is a reply to message #31781] Sun, 27 March 2011 22:51 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
mirek wrote on Sun, 27 March 2011 10:02

Mindtraveller wrote on Sat, 26 March 2011 18:00

zsolt wrote on Sat, 26 March 2011 00:55

BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.

What if in the main cycle the the newly created client socket is processed in another thread while server socket is free to accept more connections?
while (run)
{ if  (serverSocket.Accept(&clientSocket)
  {
    GetThreadFromPoolAndProcess(clientSocket);
  }
}



Actually, this can be quite nicely with something like

while(run) 
{ if  (serverSocket.Accept(&clientSocket) {
     DoWork();
  }
}


and then simply starting several threads to run this loop (with single clientSocket). As accept is reentrant and MT safe, it would return only for single thread running, thus managing the thread pool.



This is a very elegant way to solve the problem using threads.

My only problem with MT in situations like this is, that a few things in Upp are global, such as lenguage-dependant setups (e.g. date or number formatting).

It is a common requirement now from a web based app to show content in the user's language, so I think multi process arrangement would be better.

Or is it somehow possible to make these global Upp settings thread local?
Re: SCGI Class [message #31791 is a reply to message #31787] Mon, 28 March 2011 08:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
zsolt wrote on Sun, 27 March 2011 16:51

mirek wrote on Sun, 27 March 2011 10:02

Mindtraveller wrote on Sat, 26 March 2011 18:00

zsolt wrote on Sat, 26 March 2011 00:55

BTW it will not solve the problem of long running SQL queries or doing some slow communication in the scgi process.

In such situations you will have to start a lot of scgi processes to be able to handle the traffic.

Increasing that number, just allows the scgi process to have a large backlog.

What if in the main cycle the the newly created client socket is processed in another thread while server socket is free to accept more connections?
while (run)
{ if  (serverSocket.Accept(&clientSocket)
  {
    GetThreadFromPoolAndProcess(clientSocket);
  }
}



Actually, this can be quite nicely with something like

while(run) 
{ if  (serverSocket.Accept(&clientSocket) {
     DoWork();
  }
}


and then simply starting several threads to run this loop (with single clientSocket). As accept is reentrant and MT safe, it would return only for single thread running, thus managing the thread pool.



This is a very elegant way to solve the problem using threads.

My only problem with MT in situations like this is, that a few things in Upp are global, such as lenguage-dependant setups (e.g. date or number formatting).

It is a common requirement now from a web based app to show content in the user's language, so I think multi process arrangement would be better.

Or is it somehow possible to make these global Upp settings thread local?


I guess that while there is no direct support, it is in fact quite easy to do in app, as there is:

String     GetLngString(int lang, const char *id);


-> #undef t_, replace it with your own version which is thread local... Or perhaps just use 'lang' parameter.
Re: SCGI Class [message #31820 is a reply to message #31791] Tue, 29 March 2011 21:27 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
Thanks, but I think, there are problems whith some code in Core like this:
static char s_date_format[64] = "%2:02d/%3:02d/%1:4d";

void   SetDateFormat(const char *fmt)
{
	strncpy(s_date_format, fmt, 63);
}

String   Format(Date date) {
	String  s;
	if(IsNull(date))
		return String();
	return Format(s_date_format, date.year, date.month, date.day, DayOfWeek(date));
}
Re: SCGI Class [message #35422 is a reply to message #31820] Sat, 11 February 2012 19:34 Go to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
I'd really like to have a working MT example on this.....

Max
Previous Topic: How should we deal with SQL column names in conflict with SQL standard keywords
Next Topic: What's up with Google subversion mirror?
Goto Forum:
  


Current Time: Thu Mar 28 18:39:19 CET 2024

Total time taken to generate the page: 0.01529 seconds