Glacier2 multiple sessions per user

xdm

Hello is posible create multiple sessions for the same user in glacier2?

i getting this exception when try to create second session for a user

WebApplicationService-WebService: warning: dispatch exception: Glacier2::CannotCreateSessionException

Thanks in advantage

marc

No, that's not possible. You can only create one session per user. If for some reason you need multiple sessions per user, you should use multiple Glacier instances.

xdm

i have now tow diferent client applications and one is able of create multile sessions per user the other get a exception session already exist


the first application is a simple console app tha create a session with a fixed user and ends but session continue to live for a few seconds and if i run application multiples time it create multiple sessions before destroy previous sessions.

the second application is a service that create and store sessions for users that goes throw a webserver. in this service if i try to create multiple sessions i get the Glacier2::Exception SessionAlreadyExist

is ice detecting that console app is destoryed and is this the reason that permit me create multiple sessions in the console app?

I need a workaround to Glacier2 multiple instances, in my case i can determine the number of sessions that a especia user as nobody can open, I thinking in dinamicaly add alias for this especial user but is not a clean solution.


note:
I have a difrent config my service has not set Ice.Default.Router and cosole app yes.

i don't use this property in the service beacause it store other Proxys that aren't accessed throw Glacier2 session

marc

Actually, I was wrong with what I said before. You can have multiple sessions per client with Glacier2. However, you can at most have one session per connection. So if you want an additional session, you must use a different connection. You can force a proxy to use a separate connection with the ice_connectionId() operation. Please see chapter 34.3.2 "Connection Reuse" for details.

xdm

Hi again

I changue my server to create a new connection each time it's create a session but when create a lot of sessions (100per second) with a hight timeout (600s) Glacier2 goes down with the next asertion

glacier2router: error: cannot create thread for request queue:
Thread.cpp:551: IceUtil::ThreadSyscallException:
thread syscall exception: Resource temporarily unavailable
glacier2router: ClientBlobject.cpp:30: virtual Glacier2::ClientBlobject::~ClientBlobject(): Assertion `!_routingTable' failed.
Killed

and the service that's create the sessions get's this exception

BEGIN ShopSessionI::create login: root
createShopManager for sessionId: _root/EB6497C2-4161-47CA-A37E-008FCF1F26A1
Exception name: Ice::ConnectionLostException file: TcpTransceiver.cpp
END WebApplicationManagerI::createSession

Here is the code for createSession

Oz::Base::SessionPrx 
Oz::Web::WebApplicationManagerI::createSession(
	const std::string& login,
	const std::string& password,
	const Ice::Current& current)
{
IceUtil::RWRecMutex::WLock sync(*this);
std::cout<<"BEGINS WebApplicationManagerI::createSession"<<std::endl;
Ice::CommunicatorPtr ic=current.adapter->getCommunicator();
Ice::RouterPrx defaultRouter =  Ice::RouterPrx::uncheckedCast(
	ic->stringToProxy(ic->getProperties()->getProperty("router")));
if(!defaultRouter)
{
    std::cerr <<": no default router set" << std::endl;
}

router = Glacier2::RouterPrx::checkedCast(defaultRouter);
if(!router)
{
    std::cerr <<" configured router is not a Glacier2 router" << std::endl;
}
Oz::Base::SessionPrx sessionPx=0;
try
{
	router=Glacier2::RouterPrx::uncheckedCast(router->ice_connectionId(IceUtil::generateUUID()));
	sessionPx=Oz::Base::SessionPrx::uncheckedCast(
		router->createSession(login,password));
	sessions[sessionPx->getId().name]=sessionPx;
}
catch(Glacier2::CannotCreateSessionException ex1)
{
	std::cout<<"Exception creating session for user: "<<login<<" reason: "<<ex1.reason<<std::endl;
}
catch(Ice::Exception& ex)
{
	std::cout<<"Exception name: "<<ex.ice_name()<<" file: "<<ex.ice_file()<<std::endl;
}
std::cout<<"END WebApplicationManagerI::createSession"<<std::endl;
return sessionPx;
}

I test with a small time out 1s and 100 concurrent clientes creating a sesion each second and seems to be stable for 30 minutes that i test it.

I don't understand why Glacier2 is killed.

Any ideas to manage this escenario in what a servant create sessions for clients that goes throw a webserver, sessions has not a hard process load but number of sessions is most important

I use linux 2.6.14
gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8
Ice-3.0.1


and other tow more question is maximun number of connections limited by the OS? can this be chnaged in a linux box?

marc

Glacier2 simply runs out of resources. It cannot create more threads. The reason can be that you simply create too many simultaneous sessions (each session consumes 1-3 threads, depending on what kind of buffering you use), or that you have your operating system configured to only support a very low number of threads.

(Glacier shouldn't assert, of course; it should print the exception, and simply refuse the session if it runs out of threads. We will fix this.)

xdm

I investigate a bit more the problem and observer that glacier2 runs out of threads when top say that are 600 task runing.

i add this properties to glacier2 config but resuls are the same

Ice.ThreadPool.Client.StackSize=8
Ice.ThreadPool.Server.StackSize=8

Can any body sayme is 600 task are a reasonable number for a PIV hyperthreading 3Ghz and 1 GB RAM.


how is the correct way to scale number of simultaneos connections, setup and other glacier2?

how avoid that Glacier2 assert and goes down, is normal that clients aborted when glacier2 goes down?

marc

xdm wrote:

I investigate a bit more the problem and observer that glacier2 runs out of threads when top say that are 600 task running.

i add this properties to glacier2 config but resuls are the same

Ice.ThreadPool.Client.StackSize=8
Ice.ThreadPool.Server.StackSize=8

I don't think this setting is relevant, since you run out of threads, not out of memory. (As an aside, this is virtual memory, not physical memory. This means that if you use a 64-bit Linux, then you can also use very large stack sizes.)

xdm wrote:

Can any body sayme is 600 task are a reasonable number for a PIV hyperthreading 3Ghz and 1 GB RAM.

Yes, with Linux light-weight threads you should be able to create 1,000's of threads -- provided that you have enough memory or that your stack size is reasonably small. (Again, a 64-bit system helps wrt the thread stack size limitations.)

xdm wrote:

how is the correct way to scale number of simultaneos connections, setup and other glacier2?

There is really not that much you can do on the Glacier side. You should look into how to increase the number of threads per process. This is a Linux configuration issue, and doesn't really have to do with Ice.

xdm wrote:

how avoid that Glacier2 assert and goes down, is normal that clients aborted when glacier2 goes down?

As I wrote before, the assert is a bug. What should happen, is that Glacier simply continues with rejecting new sessions if it runs out of threads. You could try to simply remove the offending assert.

If a session is rejected, then it is normal that a client gets a ConnectionLostException.

xdm

I swith my system to use nptl

must I recompile Ice for this?

with nptl now i get a diferent exception from glacier

glacier2router: error: cannot create thread for request queue:
Thread.cpp:551: IceUtil::ThreadSyscallException:
thread syscall exception: Cannot allocate memory
glacier2router: ClientBlobject.cpp:30: virtual Glacier2::ClientBlobject::~ClientBlobject(): Assertion `!_routingTable' failed.
Aborted

when this ocurrs top report at least 500MB of RAM are free i a bit confused about this.

is a correct design patterm put serveral glacier2 to increase the number of concurrent users that and Ice system can handle?

marc

No, you don't need to recompile Glacier2. What seems to happen now is that you require too much virtual memory. For example, if your thread stack size is 256KB, and you use server-side buffering, you need 512KB of virtual stack memory per client (two threads per client). With a 32-bit OS, you can have a maximum of 4GB of virtual memory. This means that your theoretical maximum is 8192 clients (less than that, because you also have the main thread and a few other internal threads, plus other memory that Glacier2 needs to allocate).

Reduce the thread stack size, or use a 64-bit linux... or reduce the number of clients connected to a single Glacier2 instance (you can use multiple instances on multiple hosts instead).