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.