Hello Sumit,
I would not recommend you to go 2nd way... Main selector thread most
of the time is under load, because it processes a lot of clients, so
if you will decide to put there some client processing logic - it will
reduce (in many cases *dramatically* reduce) the total number of
clients your server will be able to serve.
As I understand you have scenario, where request processing takes a
long time (some complex computation, big database requests etc) and
you don't want processing thread block until the request will be
processed... Is this correct?
Can you pls. describe your usecase, it will help to find appropriate
solution.
Thanks.
WBR,
Alexey.
On May 21, 2008, at 15:08 , sumitsureka wrote:
>
> Hi Alexey,
>
> I have one query, that is it possible for me to use the same thread
> of the
> Selector instead of creating multiple worker thread.
>
> Or something like though it creates multiple threads, but i do not
> want to
> send the response immediately, so instead of making the thread
> waiting, it
> should return and I shall send the response later.
>
> But as per grizzly structure, it seems that response should be sent
> in the
> same method i.e. services which has request and response as the
> arguements.
> So, is it possible that I can send the response later through the same
> connection i.e. asynchronously.
>
> Something like this (both ways):
>
> First Case:
> ========
> MainThread:
> Start Grizzly
> Wait for Request
> If Request is available in the Queue
> ProcessRequest()
> RemoveRequestFromQueue()
> sendResponseToGrizzly()
>
> GrizzlyThread:
> loop (until server is running) {
> Set<SelectionKey> readyOperations =
> selector.select(); // Just
> one Thread here is blocked and waits for events on several sockets
> for-each(readySocketOperation : readyOperations)
> { // Iterate throw all ready events happened on registered
> sockets
> Thread taskAssociatedThread =
> getTaskExecutorThreadFromPool(readySocketOperation);
> taskAssociatedThread.start();
> }
> }
>
> TaskAssociatedThread:
> processSocketEvent(selectionKey);
> Place the request in the Queue
> returnThreadToPool();
>
> Here I am not sure as how to implement "sendResponseToGrizzly()" as
> the
> original request thread has already returned.
>
> Second Case:
> ========
> MainThread:
> loop (until server is running) {
> Set<SelectionKey> readyOperations =
> selector.select(); // Just
> one Thread here is blocked and waits for events on several sockets
> for-each(readySocketOperation : readyOperations)
> { // Iterate throw all ready events happened on registered
> sockets
> ProcessRequest();
> }
> }
>
> For this, I did tried to do something similar byt defining Min and Max
> thread as 1, but Grizzly internal has a minimum thread of 5 and not 1.
>
> The reason I want this is that I do not want too many threads
> staying idle
> for other thread to process the request.
> It will be great if I can go ahead with the First case as that is more
> reasonable where the thread immediatlely returns once they complete
> their
> part and the other thread sends the response to the same connection.
>
> Thanks,
> Sumit
>
>
>
>
> Oleksiy Stashok wrote:
>>
>> Hello Sumit,
>>
>>> Thanks for information.
>>> I am very new to this NIO stuff, but what I understand is that using
>>> Selector i.e. part of the NIO Java NIO libraries, a large number of
>>> I/O
>>> channels can be monitored and serviced by a single thread.
>> Correct.
>>
>>>
>>> But as I was executing my code, I can see that internally grizzly is
>>> created
>>> one worker thread for each request. So, I am uanble to understand as
>>> how can
>>> I get the facility of Selectors, might be that I have missed some
>>> properties
>>> that needs to be set. If I start using one thread each for one
>>> request, then
>>> that makes things similar to servlet approach which shall not be
>>> efficient
>>> in terms of resource utilisation and performance.
>> Well, to process the request in any case you need a processing
>> thread,
>> which will execute the logic.
>> What NIO brings - is possibility to use single thread to wait for IO
>> events on several connections. This means, that you don't need to
>> associate one thread with each connection at time when nothing
>> happens
>> on a connection. But once some IO event come on some connection - you
>> can either process it in the same thread or assign thread from pool
>> to
>> process connection event. In other words we don't associate a
>> connection with a thread anymore, but a connection *task* with a
>> thread.
>>
>> For example OLD IO does following:
>>
>> AcceptorThread: // main acceptor thread (server socket)
>> loop (until server is running) {
>> Socket socket = serverSocket.accept(); // Accept a socket
>> Thread socketAssociatedThread =
>> createThreadForAcceptedSocket(socket); // Associate socket with
>> thread
>> socketAssociatedThread.start(); // Start socket thread,
>> which will live during the socket lifecycle
>> }
>>
>> SocketAssociatedThread: // thread associated with each socket
>> loop(until socket is alive) {
>> waitForSomeEventOnSocket(socket); // thread is
>> blocked here until some data will come on socket.
>> executeEvent(); // process the data
>> }
>>
>>
>> NIO:
>>
>> MainThread:
>> loop (until server is running) {
>> Set<SelectionKey> readyOperations = selector.select(); // Just
>> one Thread here is blocked and waits for events on several sockets
>> for-each(readySocketOperation : readyOperations)
>> { // Iterate throw all ready events happened on registered
>> sockets
>> Thread taskAssociatedThread =
>> getTaskExecutorThreadFromPool(readySocketOperation);
>> taskAssociatedThread.start();
>> }
>> }
>>
>> TaskAssociatedThread:
>> processSocketEvent(selectionKey);
>> returnThreadToPool();
>>
>>
>> Hope it's more or less clear :))
>> In blocking IO all the time we have thread associated with
>> connection,
>> even if nothing happens on the connection. The associated thread just
>> blocks and waits.
>> With NIO we have single thread which waits/blocks until some event
>> will happen on any of registered connections (for ex. there could be
>> 100+ connections registered on 1 selector) and can associate thread
>> with a connection just for the time, when there is something to do
>> with the connection, for example process the request came on a
>> connection.
>>
>> So Servlets could also work on top of NIO and leverage its
>> advantages.
>>
>> Hope this will help.
>>
>> WBR,
>> Alexey.
>>>
>>>
>>> Please let me know as how this can be done?
>>>
>>> This is the reference code that I am using:
>>>
>>> public class EmbeddedServer implements Adapter {
>>> public static void main(String[] args) {
>>> SelectorThread st = new SelectorThread();
>>> st.setPort(8088);
>>> st.setAdapter(new EmbeddedServer());
>>> try {
>>> st.initEndpoint();
>>> st.startEndpoint();
>>> } catch (Exception e) {
>>> System.out.println("Exception in SelectorThread: " + e);
>>> } finally {
>>> if (st.isRunning()) {
>>> st.stopEndpoint();
>>> }
>>> }
>>> }
>>>
>>> public void service(Request request, Response response)
>>> throws Exception {
>>> String requestURI = request.requestURI().toString();
>>> System.out.println("New incoming request with URI: " +
>>> requestURI);
>>> System.out.println("Request Method is: " + request.method());
>>> System.out.println(Thread.currentThread().toString());
>>>
>>> if (request.method().toString().equalsIgnoreCase("GET")) {
>>> response.setStatus(HttpURLConnection.HTTP_OK);
>>> byte[] bytes = "Here is my response text".getBytes();
>>> ByteChunk chunk = new ByteChunk();
>>> response.setContentLength(bytes.length);
>>> response.setContentType("text/plain");
>>> chunk.append(bytes, 0, bytes.length);
>>> OutputBuffer buffer = response.getOutputBuffer();
>>> buffer.doWrite(chunk, response);
>>> response.finish();
>>> }
>>> }
>>> public void afterService(Request request, Response response)
>>> throws Exception {
>>> request.recycle();
>>> response.recycle();
>>> }
>>>
>>> public void fireAdapterEvent(String string, Object object) {
>>> }
>>> }
>>>
>>> Thanks,
>>> Sumit
>>>
>>>
>>> Oleksiy Stashok wrote:
>>>>
>>>> Hi Sumit,
>>>>
>>>> nice to here that!
>>>> Actually now, using Grizzly, you can implement SOAP over "any TCP/
>>>> UDP
>>>> based transport" :) ... for example FTP or similar, as you are not
>>>> limited just by HTTP.
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>
>>>> On May 19, 2008, at 16:11 , sumitsureka wrote:
>>>>
>>>>>
>>>>> Hi Alexey,
>>>>>
>>>>> Thanks for the reply. I was succesful in doing that. I just
>>>>> implemented the
>>>>> Adpter class of Grizzly and the TransportListener of Axis2.
>>>>> Something like
>>>>> this:
>>>>>
>>>>> public class HttpServer implements TransportListener, Adapter,
>>>>> TransportSender {
>>>>> ......
>>>>> }
>>>>>
>>>>> Grizzly callbacks the method service from where we can the
>>>>> complete
>>>>> request
>>>>> through the structure "Request" which is mapped to "MsgContext"
>>>>> structure of
>>>>> the Axis and it is the input the AxisEngine.
>>>>>
>>>>> This helped me to integrate both Axis2 and Grizzly. Now I am
>>>>> able to
>>>>> get the
>>>>> benefit of both.
>>>>>
>>>>> Though Axis2 provides the embedded HTTP server, but it is not too
>>>>> efficient
>>>>> and even though their is certain restriction in the number of
>>>>> connections.
>>>>>
>>>>> Regards,
>>>>> Sumit
>>>>>
>>>>>
>>>>> Oleksiy Stashok wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> frankly I'm not sure how easy Grizzly could be integrated with
>>>>>> Axis2,
>>>>>> anyway, think, Axis2 has several transports supported (like SMTP,
>>>>>> JMS?), so you can take a look how that transports are integrated
>>>>>> and
>>>>>> make similar things for Grizzly.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>> On May 18, 2008, at 15:51 , sumitsureka wrote:
>>>>>>
>>>>>>>
>>>>>>> I want to integrate grizzly with Axis2, Grizzly as the web
>>>>>>> Server
>>>>>>> and Axis2
>>>>>>> for SOAP parsing and validation.
>>>>>>>
>>>>>>> Can anyone please help as how to do that. In Axis2, we can
>>>>>>> implements the
>>>>>>> TransportReciever and insert our own transport layer. The only
>>>>>>> problem that
>>>>>>> I am facing is how to send data to the Axis.
>>>>>>>
>>>>>>> Axis2 accepts everything inside the MsgContext (Axis2
>>>>>>> structure).
>>>>>>> So, I am
>>>>>>> not sure as how to transform everything from Grizzly Request
>>>>>>> structure to
>>>>>>> Axis2 MsgContext.
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Grizzly-and-Axis2-tp17303209p17303209.html
>>>>>>> Sent from the Grizzly - Development mailing list archive at
>>>>>>> Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Grizzly-and-Axis2-tp17303209p17316727.html
>>>>> Sent from the Grizzly - Development mailing list archive at
>>>>> Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Grizzly-and-Axis2-tp17303209p17341456.html
>>> Sent from the Grizzly - Development mailing list archive at
>>> Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Grizzly-and-Axis2-tp17303209p17364209.html
> Sent from the Grizzly - Development mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>